May 11, 2023

Product Management Fundamentals For Your Mobile App



What is the Product Management OS?

The PM OS is a framework for translating any digital product concept into a defined, specific product roadmap.  Both developers and designers can use the PM OS to guide their work on apps from initial MVP to scale-level releases.

At DreamLabs, we guide every client through the completion of the PM OS before building any feature.  This article explains why and how to use it.

Who is this for?

The PM OS is specifically targeted to 2 persona types:

  • Founder - Non-technical background looking to build an app in no/low-code.
  • Dev + Design team - Duo looking to build an app together, with no PM expertise.

Translating an app vision from a idea to developed features is challenging.  Miscommunication leads to wasted time and money, which for 0-1 products, are extremely valuable.

At DreamLabs, we’ve launched multiple products and through this experience have refined both out process as well as frameworks for translating an initial concept into a defined product roadmap ready to be built.

Product Strategy - What is it?

Before getting into the tactics, let’s start with the strategy.  What is product strategy?  Put simply; The discipline of narrowing your focus

This focus is imperative because building a company is a journey.  Your product strategy is your control center, the set of levers and dials you can use to adjust your speed, direction and orientation.  A product strategy gives both direction and momentum to what you’re building.

Product Stages (Initiatives)

Along this journey, there are 4 primary stages of product development.

1. Concept validation

  • Goal : In 1-2 weeks, put down your core idea and sell it to 10 users.  This is the “dogfood test” MIT professor Bill Aulet describes in 24 Steps to Disciplined Entrepreneurship.
  • If technical → build a rapid prototype in Bravo for your core UX.
  • If non-technical, you have a few different options:

High effort - Glide (mobile) or Softr (web) prototype
Medium effort - Figma clickable prototype
Low effort - Simple flyer/landing page

2. MVP 0-1

  • Goal : Validate Riskiest Assumption as quickly as possible. We’ll get more clear on what this means in the next section.
  • It is of particular importance to define your product vision before building your MVP to stay focused.

3. PMF (Product-Market-Fit)

  • Goal : Identify the highest value use-case from highest value user.

4. Scale 1-n

  • Goal : Realize full product vision, grow in scale, then scope.

What is your Riskiest Assumption

We agree with PM thought leaders from major tech companies that saying you want to learn from your MVP is not enough.  Instead, you write them out explicitly to keep yourself accountable to what you are setting out to accomplish.  Scientific method 101, identify your hypothesis before you design an experiment to test it.

We use a 5-part Assumptions framework to put our ideas on paper, then identify the single Riskiest Assumption.  There can only be one.  This allows you to be honest in your Feature prioritization and user feedback sessions.

PM OS Components

An overview of product strategy is good in theory, but let’s get specific with the nuts and bolts of the PM OS.

To build it, we researched a number of standard PM tools, from Jira to Atlassian to Monday, de-constructed them, identified their most essential components and integrated them in a single, integrated Notion framework.

These components are what we found as the essential building blocks of any product vision.

User stories - Ideal state

We use FigJam for this component and distinguish two separate elements:

  1. User flows → The high-level tasks that your app should enable a user to accomplish. e.g. Onboarding a new account
  2. User stories → The specific steps that bring a user from start to finish in a single user flow. e.g. Sign up for a new account, add profile information, watch onboarding video

Not every user story you map out will be live in your initial version, and that’s good.  What you outline now will not be what you end up with, if you’re doing it right.  This is your architectural blueprint and each subsequent release will unlock new layers of functionality. You’ll also iterate on your user stories as you get feedback after each release.  This is a starting sketch, not a stone tablet.


The point of writing out your features is to cut out as much room for miscommunication as possible.  Just verbally telling a developer what you have in mind is a likely to end up with them misinterpreting what you say, leading to wasted time / cost.

We’ve found the following specifics to be key in defining each feature :

  1. User story - Tie the feature to a specific user story defined above.
  2. Allows user to… - Explain what the feature should enable the user to accomplish.
  3. Assumptions - Detail both what the feature is and is not.

Once defined, then tag each feature H, M, L by:

  1. Priority - Founder or product lead
  2. Effort - Developer, based on feature definition

The result is a list of features that can then be stack-ranked.  Seeing the exact hourly breakdown of each feature helps in the release setup process.  You can’t do everything at once, but High Priority, Low Effort features are a good place to start, while Low priority, High Effort features can easily be backlogged.

Feature prioritization

As a baseline, we recommend two primary filters for thinking through your must-have features for an initial release.  Having just these two is enough to get started.

  1. Minimum feature set → Features that enable your core product concept.
  2. To define your core product concept, ask: “How would you describe your product in one sentence in a noisy bar?”
  3. Magical “wow” moments → Elements of the UX that delight your user and encourage them to continue along your ideal user flows.

With these prioritization filters in mind, make a final decision on which features must be included in your MVP release.  Assign all others to your backlog to build later.  You now know, roughly, how much development time your MVP will take!

Front End

The three components we use to set up the front-end are:

  1. Wireframes - This is your rough sketch of what each screen should look like to lay out where the features go and how they plug together.
  2. Designs - With your wireframes complete, apply your brand guidelines and design magic to complete your hifi designs.
  3. Table - Track each screen in a Notion table to have visibility in the progress of each.


The two components we use to set up the back-end are:

  1. DB Schema - It’s not glamorous, but setting up your db schema before building is also key.  This helps you get an understanding of your back-end complexity before building so that, again, you can have the information you need to make prioritization decisions from the get-go.
  2. API Outline - This last piece is most relevant for teams building in Bravo Studio.  Thinking through and defining your API calls beforehand can speed up the time your developer needs to build them out.

Next Steps

With each component completed, you are now in a place to get started in the actual development of your app.  You can rest easy knowing that each hour of effort going into both design and development are high-priority, high-value.

At DreamLabs, running this process is the first stage of work we do with every client.  We bring insights from our own expertise as well as observations of what has or hasn’t worked for other products to help each client refine their idea to best enable success.

Let us know if you’d like to chat about getting support in either:

  • Building a 0-1 MVP app
  • Defining your product strategy