What is your end-to-end product development process?

Our product development lifecycle process looks very similar to a double diamond design process but with an adapted approach for our organization. While there are best practices for a product development processes, I've found that there is a decent amount of adaptation and adjustment that needs to happen to customize an approach for the needs of the organization. I've not seen 2 product lifecycles that are the same. 

At a minimum, a product development process should help reduce friction for the R&D teams, create clarity around what we need to know before we invest, and insight into the variables that influence those decisions. The most mature and refined PDLC programs also create consistant expectations of each role that participated in the product development process, sets criteria for high quality output, and provides clarity on what to do next through each stage. This is extremely benefitial when you think about onboarding new PMs to the team, as well as supporting the growth of PMs new to the role. 

Depending on the needs and maturity of your organization, you can chooste to implement a light version of this process that focuses solely on alignment and rescource allocation, or lean more into a more detailed process that provides more clarity on activities you expect the teams to execture for each stage. 

A good process provides time and space for the team to engage in activities focused on discovery, exploration, and time in a particular problem space. In this stage. you should avoid solutioning at all costs. 

There should be a stage for concept exploration, and I strongly encourage my teams to explore more than 1 concept. Sometimes the first concept we surface is not the best for the job, but inertia and time constraints prevent us from exploring more. I recommend my teams take the time, because it saves us on the rework later. 

Once a concept has been validated, there should be a stage that allows you to define the high level requirements and start thinking about an experience that would make it as easy as possible for customers to realize value from your chosen solution for the problem space. For me, customer validation of the specific execution is critical, because we are very rescource constraigned on the engineering side. If I can prevent rolling out soemthing that needs major rework, I will. Some organizations are more constraigned on the research or PM side in which case you may use the experience itself for validation. 

There are many types of product development lifecycles, and you should choose an execution that solves the most prevalent R&D problems your organization is facing. 

I don’t believe in a universal end-to-end product development process. I believe there are key rituals and elements that should be present on every team to ensure great outcomes, but each team needs to tailor the development process to their unique situation.

My must-have product development elements & rituals:

1. Common Language - Your company should have a common language for the product development process. This is not a prescribed way to do product development for every team at the company (this needs to vary team by team for good reason).
   At Shopify, we call it GSD (get sh*t done). The base elements are a common language around Product Development stages: 1) Proposal 2) Prototype 3) Build. We have an internal system at the company where you can look at all development projects and the stage that they’re in, how long they’ve been in that stage, when they’re expected to go to the next stage.
   We also have a common calendar of 6 weeks sprints that is used by the company wide. This helps when you’re having a discussion around when do you think you will have x? This transparency and common language is key.
2. “Agile Research” - This is a term I coined to describe the act of always conducting user interviews. The problem with well-designed research projects is that they take too long and tend to deliver the insights after you’ve started building the thing. Advocate for a “rolling recruit” of your key personas so that you can tap into talking to users *every week.* This ensures you have feedback and insight in the moment you need it most before the product is built and decisions are made. Alternatively, you can create a type of Customer Advisory Board where members opt into research questions, providing feedback, etc on an ongoing basis.
3. Continuous Product Discovery - A common misconception around PMs is once a project is kicked off and being prototyped their discovery work is done. Discovery is a never-ending job. There is a lot of work to be done up front to define the problem and opportunity more broadly, but throughout the development lifecycle there are endless sub-problems that need to be found, defined and shaped.
4. Unstructured Live time with the Product Squad - At Shopify, we refer to this as "Jamming." This is the schedule I tend to implement on my teams:
   Monday - Problem Shaping, Wednesday - Live Prototyping, Thursday - Fresh Eyes, Friday - Demo. Monday and Wednesday sessions are unstructured live time with the Product Squad. PM, Eng, UX, and Data get on a call and stare at the Problem or Prototype together. PM guides the Problem Shaping meeting and UX guides the Live Prototyping meeting, but the purpose is to tap into all the brains on the team to get to the best outcomes. It can be terrifying for a lot of people. It’s like getting in the car without a destination in mind. You need to create a culture on your team where it’s ok to not have all the answers. To prepare, the PM can have “intended outcomes”, “problem definition” or “options” prepared. During the meeting, the PM facilitates getting insights from the group around what else to consider, what’s missing, etc.
5. Progress every week - Another cultural thing - you need to have rituals on your team to encourage and ensure progress is made in some way, shape or form every week. My favorite way to do this is the weekly demo AND ensure that not only eng presents, but also folks from PM, UX, etc.

I'll start with an upfront caveat - there is no one product development process.

How you go about development will depend on what you want to develop: An entirely new product? A feature? An improvement on a feature?

If I simplify - you need to:

1. Form a hypothesis on a problem that needs to be solved

2. Gather data and evidence that backup that hypothesis

3. Determine what data you would look at to know if you solved the problem and got the outcome you sought

   • User outcomes — How do you make the user or customer workflows better?
     Business Outcomes — How does this make money, save money or save time?

4. Ideate and find ways to validate a solution - whether that be via design prototypes, or in-market product experiments will depend on what you're looking to develop.

5. With a solution in mind, then you need to break it down into workable pieces of value. I favor the B.E.A.F. framework

   • Basic — What will simply solve the problem?

   • Enhanced — How can we improve on that solution?

   • Advanced — How can we expand the solution to more functionality?

   • Future — What would this looke like if we solvied it better than anyone?

6. Work with a dev team to break downthe work for the "B"

7. Check your measures to ensure you're driving to the desired outcomes (from #3)

As always, your mileage may vary based on what you are developing. Start with First Principle thinking, it can take you far beyond any generic framework or process.

The end-to-end product development process can vary based on the nature of the product, the industry, and the specific methodologies used by a company. However, a general product development lifecycle typically involves the following stages:

1. Idea Generation

2. Market Research

3. Conceptualization and Planning

4. Feasibility Assessment

5. Design and Prototyping

6. Development

7. Testing

8. Deployment

9. Launch

10. Post-Launch Monitoring and Support

11. Iterative Development

12. End-of-Life or Product Retirement

It's important to note that this process can be adapted based on the specific needs of the project, and many organizations may use variations of this framework, such as incorporating DevOps practices for continuous integration and deployment. The key is to remain flexible, customer-focused, and responsive to changes throughout the product development lifecycle.

I would describe my product development philosophy as "agile lite," meaning there is some structure but the order of operations can change based on new learnings that arise. The entire product team (product manager, UX designer, and engineers) should be involved at every stage, but different roles will play a leading role depending on the stage. Here are the stages I go through:

• Identify the problem: Product manager identifies the top customer problems to solve.

• Conduct user research: Product manager schedules customer calls to validate how large of a problem it really is. They collect use cases and get feedback on any initial design concepts, which can be lightweight wireframes and not full, clickable prototypes. UX designer and engineers should be invited to the calls to hear feedback directly from customers.

• Ideate: Product manager organizes a brainstorming session with the UX designer and engineers. Product manager identifies the top user stories to solve for and the entire team workshops ideas for a MVP.

• Create prototypes and do user testing: UX designer takes on the lead role and creates a prototype based on the brainstorm session. They then schedule customer calls to get feedback on a clickable prototype to test ease of use and whether it solves customers' pain point.

• Define product requirements: Product manager creates a document to capture product requirements once designs are finalized. While this doc can be started earlier, even as early as the "identify the problem" stage, requirements should not be finalized until you've validated what you're building with user testing. Here is a sample product requirements doc.

• Build MVP: Engineers take on a lead role once requirements are finalized. It is critical that you involve engineers all the way from the start and not just at the build stage. That way by the time you're ready to start engineering work, you've aligned on requirements and expectations and have their buy-in on the project. This collaborative process should reduce any risk of being surprised by what they've built.

• Release: Engineers release the product and product managers monitor customer feedback.

• Continue to iterate based on feedback: Even after releasing a product, it's important to continue to iterate based on feedback.

• Sunset the product [optional] : At the end of a product's lifecycle, product managers should consider sunsetting a product. While this is not a required part of the cycle for every feature release, it's important for product managers to think critically about when they need to sunset a feature to reduce clutter in their product. It's more important to have a product with helpful features rather than a product riddled with less helpful features.