Mental Model: My Product Process

Most of what I have learned about product management has been through on-the-job training. From this experience, I don’t really believe in dogmatic adherence to specific processes or paradigms. In fact, there have been a few occasions where strict adherence to process actually got in the way of building a better product. I do think though that it is helpful to use many of these paradigms as touch-points in the process. The following is the scaffolding I use for product development. It is mostly a series of questions I run through to make sure I am covering my bases when working with a team to deliver a new product or feature.

Stage 1: Uncover Requirements

Start with WHY (Alignment Exercise)

What is our shared purpose?

  1. Is it written down somewhere? – I want to frame the rest of the process through the organization’s values.
  2. What is the long-term company mission?
  3. Is there an articulated company strategy and/or product strategy document?
    1. Does the company, team, etc. have OKRs (or something substantially similar) that they measure themselves against in order to achieve their mission?

Customer Signals

Signals we are getting from our customers (or potential customers)‌

  1. Who are our customers?
  2. What do our customers want to achieve?
    1. What is currently getting in their way of achieving this?
    2. What are their perceptions of their pain points?
    3. NEVER ASSUME we know what our users are experiencing and thinking
  3. What research has been previously done?
    1. Have we compiled personas? Which persona are we targeting?
    2. Do we have any customer conversations/interviews that we can review to get a better understanding of their needs?
    3. Do we have usage data?
    4. What insights have we collected from our sales, marketing, BD, and support conversations?

Market Signals

What is the business use-case (i.e what is the business model)‌?

  1. What are the trends and greater signals in the market?
    1. Broadly, what are potential opportunities?
  2. What is our competitive analysis?
    1. What do our competitors do well?
    2. What do they not do well?
  3. What is our unique insight or understanding of our world?
  4. What Metrics or Key Results are most important to drive success for the organization?
    1. What is our current and past performance towards meeting those goals? (develop base-line organization data)
    2. How much does it cost to acquire a customer?
    3. How much can we expect to earn from a customer over their lifetime? (LTV)
    4. What is our required/ideal gross margin?
  5. What is our marketing funnel?
    1. What is our process for guiding a lead or potential customer to a purchase?
  6. What is the timeline we are operating under?
    1. Is there some external pressure to release some version of this product by a certain date?
      1. Financial runway, Big Event, company fundraising, etc.

Stage 2: Start to Develop User Stories


Large focus area that spans the entire organization‌


Collection of Epics that drives toward a common goal‌


Large bodies of work that can be broken down into smaller stories ‌

  1. Naming epics: simple with no lingo and answers the core development objective or reason for why it matters
  2. Include:
    1. Intro
    2. Product requirements
    3. Design requirements
    4. Technical requirements
  3. Bigger release line‌ can also be described as epics


Written from a perspective of a user and is a short explanation of the requirements‌

  1. Structure of a User Story
    1. As a <type of user>,
    2. I want <some goal>,
    3. So that <some reason>
  2. Acceptance Criteria Structure
    1. Given <what you are trying to achieve>
    2. When <what action is being taken>
    3. Then <what the result should be>
  3. Group stories into smaller release lines

Other considerations during this process

Checks: Did you sufficiently cover all the considerations at this stage or development? ‌

Make sure to consider how you are getting U/X and Data involved early to help you shape the requirements:

  1. Can you set up a/b tests on early stories?
  2. Wireframes
    1. Usability testing early prior to development. Can you get 5 customers to give you feedback on this?
  3. Involve other idea validation strategies
  4. The goal is to get feedback as early as possible to test the idea

At the end of this stage, you have an unprioritized roadmap‌.

Stage 3: Prioritization Strategies

  1. Things to consider (constraints)
    1. Technical constraints
    2. Design constraints
    3. Business constraints
      1. Time
      2. Money
      3. Management directives
  2. MoSCoW analysis
    1. Must: requirements that have to be ratified for the final solution to be considered a success
      1. These are high-priority items
    2. Should: High-priority item that should be included if possible
    3. Could: Desirable but unnecessary
    4. Won’t: Requirement that stakeholders agree will not be implemented
  3. Weighted Shortest Job First (WSJF)
    1. Calculates a cost of delay
      1. Cost of Delay =
        1. User-Business Value +
        2. Time Critically +
        3. Risk Reduction and/or Opportunity Enablement
    2. Calculating Job Duration
      1. WSJF =
        1. Cost of Delay /
        2. Job Duration (Size)
  4. Effort vs. Impact analysis
  5. What matters most is that the team understands and is aligned on the prioritization mechanism
  6. You can start to think about ways to optimize the work and release lines
    1. Be wary of optimizing too early in the process. It can cause waste.

Remember to constantly get feedback along the way from all stakeholders


This outline is pretty bare bones. It is not meant to be a full repository of information on the entire product process. Rather, I use it to reinforce everything I have learned from other sources and my personal experience as a product manager. If you find this outline in any way helpful, please feel free to copy, paste, and alter for your own purposes. Additionally, if you have any feedback on this outline, please reach out to me on LinkedIn. I always welcome additional insights on the product development process.