The Product Development Process
Last week, I wrote a little about the people who build software products.
Now, I want to talk a little about the process itself.
It can vary quite a bit, but there are a few practices that have been common enough to discuss as ‘the way’.
Annual and quarterly planning
To decide and align on what needs to be built, product managers periodically lead a process of planning. Usually there is a big planning cycle to roughly align on what should be done on the next 12 months, and a smaller planning cycle each quarter that fills in more detail about what will be delivered within that quarter.
What that usually entails is reviewing data on the business, meeting with stakeholders to get their ideas on what should be built, deciding on business goals and product goals for the users and customers, and prioritizing the product feature ideas based on those goals.
Some questions to ask of the data and stakeholders during this period are:
What are the biggest problems and opportunities facing the business?
If we solved the problems how much impact would that have (ie how much revenue, customer satisfaction, retention, or other business goal would solving this problem drive)?
If we can’t solve the whole problem immediately what are the intermediate steps to get there?
This can be a difficult process. Different stakeholders are incentivized to prioritize problems differently, so they may be in conflict about what to ask the product team for. Ultimately it’s up to the product manager to resolve the conflicts and set the priorities for the product team.
The output of planning should be a product roadmap
Product Roadmaps
With planning and relative priorities as inputs, product managers consult with the engineering managers and designer to decide roughly how long it will take to implement solutions to the problems raised in planning.
They can then decide what projects to do when and how long they will take.
They can lay this out in a chronological view, which is what we call a product roadmap.
Roadmaps are important artifacts for a few reasons.
They provide a way for development teams to organize their work, with milestones and timelines to hit for product delivery
They provide a way to show the rest of the company what to expect from the product team and to plan around different product milestones
They can provide a tool for sales and marketing teams to talk about features that improve the products for users and customers.
Product Definition
With a roadmap in place, the product manager and the team have to get a little more detailed about what the solution should look like and what it should do.
At this stage, they will talk to stakeholders, customers and users to determine the ‘requirements’ of the product. Requirements are what the product has to do to solve the user or business problem. It also includes what the product does not have to do.
One output of this could be what is known as a product requirements document (PRD)
Product requirements document (PRD)
The PRD varies a ton in its format, length and level of detail between companies, but what it usually includes is:
Background - giving a little context about how we came to realize that this is a problem and how big a problem it is, and why we want to solve it
Use cases, ‘jobs to be done’ or high level user stories - these are all terms for a description of what the product does for a certain type of users. An example would be ‘As a clinician working with patients at HealthX, I want to see all relevant clinical data at the point of care, so that I can achieve the best outcomes for my patients’. A PRD would contain a handful of such use cases that the product should help with or solve
Scope - what problems should be addressed and what problems should not be addressed. This is important to lay out, because often there is a temptation to build cool features or things that people are asking for into a product that can take up engineering and design resources but don’t actually solve a high priority problem
Outstanding questions - running list of things we don’t know but need to know to get to a good solution.
It may also include:
Low fidelity designs
Links to other documents like high fidelity designs in progress, a technical design document, etc.
Research & Design
With the high level requirements understood, the product manager will work with the designed to flush out the user’s problems on a more and design the user interface components and the user’s journey through the product.
Research
A typical process involves the designer and product manager leading interviews with prospective users to understand their problems and expectations. Engineers from the development team are often invited, but usually don’t plan the interview and only ask follow up questions.
Prototypes
Using the requirements document and interviews as input, the designers will make prototypes of the interface a user would expect to use, taking into consideration the full journey and interactions with different aspects of the product.
Often the product managers and engineers are consulted for feasibility and scope considerations during this process, but the designer is in charge.
Testing
At one or more stages of the prototyping phase, designers will show their designs to users or other people to get feedback on whether the designs are usable, and whether they would solve the user’s problem. User feedback can be incorporated into future iterations of the design.
Final design
When the designs are completed, the design team works with the engineering team and product manager to implement the designs. Throughout the implementation process, engineers will consult the designer on visual aspects or feasibility of the proposed solution.
Implementation
Agile and scrum
Agile and scrum are widely accepted methodologies for project management and software development that describes a two week time period as the basic unit of work for getting projects done. I’ll describe some of the basic units of this workflows here, but there is much more at the Atlassian site I linked at the beginning of the paragraph and here at the scrum guide.
In practice, these methodologies are not usually implemented as strictly as they are described, but the key units I describe below usually are.
Sprints
Sprints are two week units of work, and are the basic unit of scrum product management. It will include sprint planning, ‘grooming’ or writing and updating the basic units of work of a sprint (known as stories or sometimes just tickets), Retrospectives (mostly just called ‘retros’), and stand-ups.
Aside from those meetings, the work of the developers on a product team during the course of the sprint is to try to complete all the work assigned to them at the beginning of the sprint.
Planning
Sprint planning happens once every two weeks. The product manager and engineering manager will go over the highest priority pieces of work and assign them to members of team. They will make an attempt to assign the right amount of work that can be done within the two week period of that sprint.
Grooming
A grooming meeting with the whole team once per sprint, usually on the week when planning is not happening.
In a grooming meeting, the team reviews the tickets being worked on in current sprint to see if any context needs to be added.
They also review tickets or stories for upcoming sprints, and fill in the details that are needed so a team member can pick up each ticket, read it and know what they have to do to implement the work described it it.
Retros
Retrospectives (retros) happen after the end of the sprint, and are a place to discuss what went well, what could have gone better, and what the team learned. During a retro the team can discuss any points of tension, and the team can write down what needs to be improved in the form of action items, which can be assigned and reviewed at the next retro.
Stand ups
Stand ups are a daily meeting for a product development team. Usually, each team member goes around to tell the rest of the team what they have been working on since the last stand up, what they will work on before the next one, and anything that’s preventing them from doing their work (known as blockers), so that the rest of the team can help them get un-blocked. These are usually short meetings of about 15 minutes.
Variations
There is plenty of room for variation within this very loosely generalized version of the process. For example, engineering teams may not work strictly in sprints. They might instead choose to use a Kanban system of just picking up new work when they finish what they are working on, instead of having work formally assigned at the beginning of a two week period.
There is also the waterfall method, where there is in theory less flexibility in what is planned and what is executed.
An interesting variation of user testing is described in the book Creative Selection by Ken Kocienda. It recalls the Apple software development process where the key unit of testing was the demo for other Apple employees, who used their own intuitions and taste to judge products and features throughout the design and development process.
Ultimately there are a lot of different ways to build software, and I have never been in a place where everyone did everything exactly as described above, but it is a good guideline to start with.