When do you use a product alignment framework?

The product alignment framework is something that teams should have as a guaranteed way to behave whilst in a product development sprint. In fact, the best product organisations will operate a number of frameworks entwined to ensure they correctly measure success against their desired outcome.

This is why it’s super important that product teams do not develop features or the roadmap independent of their marketing, sales and customer success teams. Ideally, it's cross-functional all the way.

What is product alignment?

All product teams perform detailed discovery, and therefore a framework by which to work is needed. Product alignment in product discovery helps foster team collaboration and knowledge sharing and guides opportunities within the product.

By having a framework from which you operate, you focus your approach and make it easy for the organisation to overcome product collaboration and assignment issues. It will also make it easier to scale operations and maintain the same standards and approach as your team expands. 

Additionally, a framework will simplify the documentation and results of your product discovery and impact.

How to use the framework to frame opportunities and problems

The product alignment framework relies on a series of stages and associated questions to help you deliver value. Below I will list each stage and the questions you must answer to move forward.

The Problem Statement

The problem statement is formed by answering two questions:

• What problem are we trying to solve?
• What is the opportunity that we’re addressing?

Answer these questions and you can identify your problem clearly.

Your Audience

The one question to answer here is:

• Who are we solving this problem for?

But don’t cheat. Don’t say the CFO of a B2B SaaS company. Dive deeper into your persona or ICP and understand more about them than topline demographics and fantasy lifestyles. I always operate on the knowledge that it's about learning what you don’t know. 

Interview as many users as you can, those that quit, those that stay but don’t adopt much and your super users. Segment by those standards to start and then work on how you can drive further adoption, clearly communicate value and drive up peer-led referrals by super users.

The Why

The why is always the question we need to ask ourselves. “Why this and not that” is a very simplified way of looking at this. But to answer this question, think:

• How do we know this is the right problem to solve? Why this opportunity and not others?
• Does this relate to current OKRs and if yes, which one? Or is this a proposal for future OKRs (based on business strategy)?
• Is this leading to a competitive advantage, neutralising advantage or differentiation from the competition? How can you use the data from customer research, conversations or observation effectively?

Always tie your “why” back to the user's world. What pain does this solve or how would this feature add even more value to the user's experience? Keep the user at the heart of your why and then test your ideas with real users from across the spectrum.

What Success Metrics do you Track?

I’ve produced a lot of content about success metrics of late. Time to value (TTV), the MoSCoW analysis method, pirate metrics (AARRR) and the HEART framework. All of these give you plenty of ways to measure the success of your decisions. Ultimately, whatever the framework you choose, you only have to answer one key question:

• How do we know we solved this problem?

You can only ever know this by two clear KPIs - user adoption and increased revenues.

Using Competitive Research to build a Competitive Neutraliser

A competitive neutraliser is a product feature that enables your platform to compete with or negate the competitive advantage of peer platforms over your own. If your product feature focuses on this, answer the following question:

• How did others capture this opportunity/solve this problem?

Remember this when building your framework but only if relevant to your product sprint.

Hypothesise Potential Solution Directions

The basis for every product feature should be data. However, sometimes the data shows a range of features that could be developed. Prioritisation is key, and here are some tips and questions you can ask to guide your choice:

• What high-level solution directions can we explore for capturing this opportunity / solving this problem? 
• Describe potential solutions through short descriptions or high-level sketches / low-fi prototypes (no implementation details at this stage). 
• Compare the high-level solution directions through impact vs complexity.

By answering these questions, you can formulate a single direction or compile several choices and then use a process of elimination to whittle them down.

How to use the framework to frame solutions

Now that you have a framework for framing opportunities and problems, you need a framework for solutions. Following the same example as above, I will list the areas and key focal points that your team need to continue to succeed.

The Proposed Solution

There are three things you need to focus on at this point:

• What is the scope of the proposed solution?
• What are the key features?
• How complex is it to realise the solution?

Keep your answers concise and do not labour on unimportant details.

The Rejected Solutions and Why?

Here your job is to clarify why the solution you chose is the one to proceed with, think about the following:

• Provide some context on why this solution was picked and the rest of the proposed high-level solution directions were not pursued. Any links to user research, customer data, etc.

This will help you understand how your decision-making helped make it or break it.

What’s out of scope

This is simple. List what is out of scope and for what reason e.g. budgets, timescales etc

• What is not in the scope of the proposed solution?

Doing this will keep your focus narrow.

The Dependencies Risks and Migrations

Keeping a clean concise list of your considerations for each feature or product release is key to your forward thinking. By thoroughly documenting your thoughts experiments and deliverables, you can revert to previous works when considering further features down the line.

• What are the dependencies?
• What are the risks associated with the solution (e.g. compliance, legal, privacy, security, strategic risk, operational, infrastructure stability/scaling risk, etc.) and potential mitigations?

GTM Strategy

Post features comes the rollout. Lines of communication, training and education across your cross-functional teams through alignment with your product marketing manager. Whilst the questions you need to answer are below, you should always have a clear plan for your product GTM process.

• What is the release plan? List the key milestones (e.g. dev complete, alpha, beta, general accessibility, etc.).
• What are the marketing and operational supports needed for this launch?
• What’s the pricing and packaging strategy?

Check out our article on building a go-to-market strategy for your SaaS platform for a deeper understanding.

That wraps up the solutions piece of the product alignment framework. To close us out, the final section covers what happens after launching the product.

The post-launch recap

This section of the alignment framework has two elements to cover. How you reflect and what you have learned. Let’s dive into that.

Reflect on your Success

Here you want to focus on how successful you were in achieving your goals according to your success metrics and the actual outcome.

And finally

What you Learned

After reflecting on your results and reconsidering, your approach focuses on what you learned that could take your product further. What is it that was successful and how can you build on that success for future updates and product releases?

Suppose your sprint involved any questions from your internal teams or stakeholders. In that case, you may look back at these questions and see how your results built on your hypothesis and potentially under or outperformed expectations.

Keep a list of the questions and who asked them to hand in and any extra materials e.g. user research or theoretical testing and results so that you can wrap the sprint up in a well-documented manner.

Product alignment frameworks can also be used to help tell a story and that story forms part of your user persona's life. Feel free to share this article with your colleagues and feel free to contribute to the list using your own experience in the comments section below.