“Product Development Frameworks” Aren’t Helpful. Here’s Something That Is. | by John McDonald | Sep, 2022

Here are some easy to follow, immediately usable steps to get you releasing products that your company and customers love!

Do me a favor…after you finish reading this article, I want you to search “Product Development Framework” online. Seriously, no hypotheticals here…do it! What you will find is a bunch of companies (that want you to buy their respective software platforms) providing the absolutely highest level of detail about how some of the top tech companies build products, but very little tactical, implementable advice.

Even if you do find resources that outline these frameworks in more detail, they tend to leave massive gaps and require you to go down a self-guided-Google-rabbit trail to learn what “Building a Value Proposition” actually means, and without a mentor beside you, there’s a good chance you will wind up more confused than you were when you started.

When I was first getting started in Product, I knew I needed a map to get from “idea” to “shipped” solution my customers and company love (which is what these Frameworks are designed to provide), but it is challenging to find pragmatic frameworks that are detailed enough to make sure you don’t miss any major steps, but open enough that let you adapt them to your unique business.

There are great books, like Dan Olson’s “Lean Product Playbook” that get into a lot of tactical detail (and I do advocate you read it, if you have time), BUT if you’re anything like I was, at this point you just want some bullet points laid out so you can start to experiment and explore on your own.

This is precisely what I am going to provide here: This “questions driven framework” provides practical guardrails to guide and focus your limited energy and time along the path to building the right solution for your customers and company.

By providing answers to these questions, you will be amazed how much more holistically you (and your team) will be able to look at your product, and best of all, this framework is incredibly simple to add to overtime as you adapt it to fit your business!

Disclaimer: While I will lay these out in the order that I tend to tackle them, they often will overlap/need to be re-ordered depending on your product/business.

Oh, almost forgot to mention — did you know you can listen to this article on the go? On your Mobile App click the “Play” button next to the “Bookmark” and “Share” buttons at the top to have it read to you by a surprisingly soothing artificial voice!

OK, let’s get started.

This is, almost always, where you need to start. It may be that your boss, or founder, has come to you and said “I need you to build X and get it live next quarter”, and while I would advocate this is not indicative of a healthy product development environment, this might just be a reality you have for the time being. That’s OK. There is still (normally) a real customer need beneath this request, and the first step is to identify who this customer is what this need, and really (and I mean really) start to understand it.

1. Who is/are the persona(s)? I can almost guarantee that your product has multiple personas (types of users), regardless of what you have thought/been told. Spend some time thinking more deeply about how this user is, what their context is, how they think, and what they like/dislike before answering this. Get specific (and if you haven’t build a persona before, this is a good time to do it — you can Google this one safely, there is a lot of tactical guides online for this).
2. What is the customer need we want to provide a solution to? Simple enough — what problem are you solving? You are not at the point where you need to write user stories, so explore/record this in some degree of long-form depth.
3. How is this customer solving this need today? Sometimes you will discover a completely unmet need, but odds are your customers are doing something already to solve for this need, at least partially. Exploring and documenting this will let you better uncover some particularities about the types of solutions/behaviors your customers are prone to using, as well as what some quick, iterative wins might be, should you release an MVP that can solve for the big pain points with their current solution right away.
4. How important, and how underserved is this need? In other words, it’s “Gap Analysis” time. Don’t let this fancy name scare you off. What you are looking for is a matrix that shows how important a given problem is to your user (X axis), and how well (or poorly) their current solution solves for this problem (Y axis). You can collect this information via surveys, chatting with the customer advisory board, or even through internal intelligence channels, like your customer success team. Typically you are looking to make sure the problem you have identified as a solution candidate has a high degree of importance to the customer, and a low degree of satisfaction within the current solutions.

Once you’ve determined that a customer has a need, and that this need has a higher “value to satisfaction” ratio (Gap Analysis), it’s time to determine whether or not solving this need is worth it to the business. In other words, what value is created, and at what cost? (Marty Cagan talks a lot about exploring the tenant of value in his book, Inspired, which is another great read).

One important thing I want to note, before we get to the questions, is that there are different kinds of value other than pure monetary gain. As a startup venture you may value customer acquisition over all else, profits be damned (very common, by the way), and so in this case you would not be looking to measure how much money an opportunity holds, but instead how positively your customer acquisition strategy could be impacted. If you are reading this and thinking, “Gosh…I don’t actually know what the primary value driver my business/team wants to achieve,” I’d encourage you to spend some time with your leaders to really dig in here. This is crucial to have a solid understanding of before we move on, as we will be measuring our ultimate solution not on output (did we release the thing?), but outcomes (did the thing give us the value we were counting on?).

We will be measuring our ultimate solution not on output (did we release the thing?), but outcome (did the thing give us the value we were counting on?)

1. What is the opportunity to the business if we solve this problem? Simple enough. You’ll turn this (and other factors) into even more measurable metrics down the road, but right now spend some time thinking through all the possible positive outcomes solving this problem could bring. Write them all down. Expand on them. Chat with members of your team/leaders to validate and get their thoughts.

This is a tough one. No one likes starting off an otherwise hopeful exercise thinking about what could go wrong, but unfortunately this is pretty darn important. Up until now you have identified a real customer need, that is more valuable/unmet than other needs, and you’ve managed to describe how it could positively impact your business’ KPI(s). Hear me out there…more risks will surface as you continue through the product development process, it is inevitable, but it’s important you spend some time right now penciling down anything that comes to mind.

Think about your funnel, your user’s journey through your products, other features or pages that might be pushed below the fold when this is released, how this will impact localization or newly launched geographies, or user personas that you are not targeting with this feature. A quick 30 minute call with your key stakeholders and the rest of your product team can be a helpful way to brainstorm risks and get enough down to feel comfortable moving along.

Oh, and one more thing…you may determine that, for whatever reason, the risks are just too great to continue with this solution. Believe it or not, this is a GREAT outcome. The worst thing you can do, for everyone involved, is diligently pursue a solution that will end up in napalming your current product. This is all part of the process, and this is the reason that you have multiple problems in your problems backlog (an article for another day).

By the way… this ability to say “No” to a solution, is a really, really important skillset for a product manager to have, and I explore this in more detail in the article below.

What are the possible negative outcomes if we solve this problem, or solve it in the wrong way?

Notice what the title says, you might have missed it…“Define”. I didn’t say “Design”. This is intentional. Before we get deep into design with our UIUX team, we need to describe what this solution will be. How it will feel. What it will involve. At this point we are talking about making a Google Doc, not a Figma file. But I want to make one really important point before we get into the questions for this one: It’s very important that you approach this step of the process collaboratively.

As a Product Manager your job, despite what you may have been told, is not to hand a list of requirements to a designer and engineer, and hope for the best. This is too big of a topic to cover in as much detail here as I would like, but my main tip is to simply keep your developers and designers engaged early on. The next step and this one are often swapped around, depending on how your team functions, but make sure especially your tech leads and principal designers are involved almost from the get-go.

It’s very important that you approach this step of the process collaboratively. As a Product Manager your job, despite what you may have been told, is not to hand a list of requirements to a designer and engineer, and hope for the best.

1. What data do we have to support this solution being the right one? I think this is an important question to ask, as grounding ourselves in data (qualitative or quantitative) is almost always a good idea, BUT don’t get hung up here. It’s OK to operate on a hunch — you are in the role you are in likely because you have a strong product sense, and this can be more of a “gut thing” than anything else.
2. What are our measurable goals with this solution, and what metrics will we use to track progress towards these goals? You have to create measurable metrics in order to know whether or not your solution is a success. Period. If you do not have data analytics tools (likely if you are at a very early stage startup), your one metric could simply be that key business KPI we discussed earlier. “Achieve a 15% increase in monthly new user sign ups”. Ideally you are able to build in a bit more granular metrics, as these “top level” metrics can be influenced by many things, which makes it hard for you to know, definitively, if the solution you released is the culprit for this change. Also, keep in mind once there is an actual design crystalizing, you can augment these metrics to make them more detailed (and you should always be coming back to these and scrutinizing them, anyways).
3. Can the team operationally handle this solution? Oh boy, this is a really important one. Most features are not released inside a digital vacuum. In other words, the solution you release will likely impact other teams in your company: maybe the Client Success team will need to build new training materials, the Operations team will need to manage the distribution, the sales team will need to be able to demo it, and so on. Think through the chain-reaction this solution will have in your company, and make sure you are able to build in support along the way.
4. Who are our stakeholders that we will need to have involved in the solution? Again… not released in a digital vacuum. You’ve possibly got business sponsors, key stakeholders in other departments, other product teams that are reliant on your work, etc. Make sure you have these people accounted for (building a simple RACI diagram is a good way to do this), and communicate with them appropriately.

Let’s not make this one too complicated…just talk about it! Evangelize it! Ask members of the team to challenge it! When I’m coaching new PM’s, and I’m asked “what’s the most trait for a PM” to have, one my go to responses is “collaborative”. One of the biggest inhibitors to a PM’s ability to collaborate is ego. In this vein, please repeat after me: “I am not the smartest member of the team. My co-workers are creative and intelligent and have good ideas. Talking with others makes my ideas stronger.”

All kidding aside, it’s really important that you keep your team and stakeholders informed, and invite them into the process. In a future article I’ll write about how to hold a Kickoff meeting (a key tool for socializing the work), but for now let’s just get to the questions.

One of the biggest inhibitors to a PM’s ability to collaborate is ego.

1. Does my product, design and engineering team know what we are looking to build, and why?
2. Does the rest of the company know how this may end up impacting their work? This was alluded to above, but to restate: your solution does not exist in a vacuum, so it’s critical you socialize with other teams as well. Do this early, and often.

If you’ve followed me for any amount of time you know how I love me a story map. I think within our craft there is little else as simple, elegant and effective. If this term/concept is new to you, I’ve got another article that goes into Story Maps in more detail (link below), and Jeff Patton’s creatively titled book, “User Story Mapping”, is the bible for story mapping, and a must read for every PM. Seriously — buy/read the book, you won’t regret it.

The reason you are story mapping at this stage, is because you need to figure out what user-oriented functionality you are going to be designing and releasing, and how your V1/MVP will organically flow into V6. Step into your user’s shoes and imagine them using your solution. What steps do they take? What are the details? Challenges? Next you slice this into iterative releases to determine what the simplest (yet viable and valuable) 1st release is for your feature. We want to get this solution into the hands of our users ASAP so we can learn and iterate.

1. What is the iterative release strategy? (Can we define an MVP that will let us test the product before it even hits the market?) The answer to this question is the story map itself!

Armed with your story map, it’s time to get into design. At this point your designer, whose job it is to make sure the solution is useable and understandable, will largely take the reigns, but this does not mean you dis-engage. It’s in the testing of the UX where I like to be as involved as my designer will let me be. Getting to observe a “cold user” walk through a prototype, and explain their thoughts and observations out loud is a powerful experience and almost always reveals new opportunities/issues that you and the team never considered.

1. What is the simplest prototype we can use to start testing with users/internal team members? I love wireframes/lo-fi prototypes (keep in mind that not all designers do). They keep the user focused on the functionality, not the visual design, which is the hardest thing to get right (and the most important). As soon as the solution has some firm definition, have your designer put together a prototype that properly demonstrates the UX (but not the visual/UI design), and have them set up some UX research sessions. Make sure to socialize the prototype internally and set up some sessions to gather feedback.
2. What do we need to change/iterate on, and how can we make these iteration cycles as quickly as possible? Design is a step where things can get endlessly hung up, if you/your designer allow it. It’s so easy to get locked in this endless “but what if we changed this little element over here” cycle. Don’t let this happen. Go through (quickly) the Design->Test->Iterate cycle enough times to have confidence that the prototype works for your customers, and get it into development so you can start getting real feedback from actual users. An old mentor of mine always stressed to me that “working software beats a prototype any day”. I couldn’t agree more.

Working software beats a prototype any day.

Story map, ✅. Working, validated prototype, ✅. Now it’s time to get into the weeds with your developers, scrutinizing the designs and the story map, to make sure detail is added, questions are answered, error states analyzed, etc. This is a really awesome time to bring in QA, if possible. Disclaimer here: you definitely want to be engaging engineering before your design team gets too deep into the weeds, as they can help you begin to validate what is feasible, and what would be WAY to challenging to build, etc. The output of this workshopping is to get a heavily annotated version of your story map, complete with Acceptance Criteria.

1. How can we take these user stories and break them down into workable tasks for engineers? The meat of this step, and it is absolutely best done in a collaborative, synchronous setting. Doing this asynchronously will lead to a bunch of “well, I thought you meant…” moments.
2. What is the acceptance criteria for each story? Your acceptance criteria represents what needs to be true for a story to be considered “Done”, in addition to the standard QA tests and validations required to get something into production. Writing excellent ACs is an art-form in and of itself, and I would be lying if I said I was an expert here. Again, this is a topic that has a lot of solid, tactical advice readily available online.

Now that you’ve got this heavily marked up version of your story map (probably complete with a good bit of change), it’s time to get all this detail into User Stories that can live inside a tool like JIRA for the rest of the engineering team to work on. Your Product Owner/Tech Leads will come in handy here again, as one of the major steps at this point is to determine how best to break down these stories into things that are small enough to deliver within a Sprint, and can be demonstrated as working software once complete.

1. What are the user stories that my engineering team can start to take into Sprints? Again, the meat of this step. This is where these detailed sticky notes get turned into the classic, “As a ____, I want to _____ so that I can ______”. The Acceptance Criteria is where a lot of the extra details can live. When written well, shared within the context of the story map as well as the prototype, your team should be very clear on what you need to deliver.
2. Are they small enough for the team to start to work on them? This is a hard one, and if you are lucky enough to have a PO/Scrum Master, they can lend a hand here. One trick a former Scrum Master taught me was that if there is an “and” anywhere in the user story, it probably needs to be broken down into multiple user stories.

OK, super important (and likely you’ve been threading this one through all the other steps the whole time)…your engineering team is happily writing code, but what does “Release” mean for this solution? What are the non-code deployment items that need to happen to get this thing out into the wild? Training materials? Updates to the sales team? Marketing and/or promotional channel activities? Communication plans? Additional data tags to enable all the great metrics you want to capture? Put together a release plan, socialize, and edit it after you get feedback — this is something you will adapt over time, as every company and product requires different types of activities to ensure success.

1. What is my release checklist? This is the release plan in its most basic form. What is all the work that needs to happen for the solution to be released, and in what order/with what dependencies? For example, this would include technical considerations like “we have to deploy the mobile feature flag before we can deploy the backend solution”, as well as business considerations like “promotional materials need to go to print on DATE in order to be ready for the launch event”. Think holistically here.
2. What would cause me to delay “launch”? Well what do you know, we are back talking about risks again! But now we are talking about launch/release risks. This is where you document what would happen if the printer wasn’t able to ship that promotional material in time — how would you pivot? What impact would this have? Here’s the thing — you won’t be able to predict everything, but just writing down the obvious risks will get you in a much better spot.
3. How and where do we need to market the solution? Almost 100% of the time you need to tell your customers/users that there is now this great new solution they need to use. While this may be the primary focus of your marketing team, you better believe the Product Manager is a core part of this process. If you are at a startup you might even wear the hat of product marketing manager as well! Talk through the marketing plan with your marketing team, and determine what dependencies they have on your team, and where additional help is needed to ensure a successfully marketed launch.
4. What kinds of internal communication is needed before and after the release? Do you want to have internal employees dog-fooding the product before it hits general availability? What about after it goes live? How can you share the results of the launch in both an informational and “momentum building” sort of way? If you work for a big company this might even include a little “tour” of sorts, showing off the work to the other squads/tribes.

You’re still with me? Good, because this is where the rubber meets the road. This is where you get to determine whether you want to be an Output or Outcome focused PM. As an Output focused PM, you would have stopped last step; sent an email that said “Look what we released! Isn’t it cool! Woohoo!” and the moved on. But you’re not an Output focused PM, are you? Nah, I didn’t think so. You care about Outcomes. This means that instead of celebrating that the solution was released (which you can/should still do), you are primarily focused on celebrating the outcomes that you wanted to achieve and DID achieve with the launch! This also means possibly sharing some harder news, such as that fact that you didn’t achieve your desired outcomes, but that you are digging into why this is the case, and looking to make some small tweaks/pivots based on this learning.

My big tip here is to share the outcomes, either way. This builds incredible accountability with your team, and helps get them focused on outcomes as well. It’s not just the PM, after-all, that needs to have this focus — everyone within the product-development-design triad should be held accountable to outcomes (even though I would argue the PM is the most responsible, given the nature of the role).

Oh, and don’t just share the results and walk away. Make sure you have sustainable measurements in place to make sure that this solution is one that you can continue to collect data on, improve and iterate over time.

1. After enough time has passed, has the release achieved the stated goals? Like we talked about — share these out.
2. Has the MTMM (Metric(s) That Matter Most), or core KPIs for our business been positively or negatively impacted by this release? The strange thing is, this business MTMM is not always 100% connected to the “product metrics” (digital signatures like click throughs, engagement, conversions, etc.). They normally are (and should be), but you want to keep this macro level view, in addition to the micro level, product-metric view.
3. What is our trigger for when we want to release the next iteration? Oh-so important. You’re not building a one trick wonder here — you are building something that should (likely) last, that you will iterate on, improve and provide more and more value from over time. Think about what would be the factors that might indicate to you that it is time to turn this skateboard into a motorcycle.

Thanks for sticking with me — I know that was a lot, but I really do hope this armed you with some key questions to start asking while you go through the product development journey. There is no one way to build products, and no matter how much I (or anyone else) might try to convince you, what works for someone else, might not work for you — and that’s ok! Building process within Product is an important part of our job, and I’d encourage you to take this, adapt it, and make it work for you.

Some of the links in this article are affiliate links, which means should you decide to purchase the product, you will also be supporting me and my writing as well!

Oh, one last thing. Would you use/enjoy a downloadable version of this framework? I’m debating building this and making it more widely available to my readers, but I would love to get a feel for whether or not you would enjoy this. Let me know in the comments below!