How To Create A Product Strategy For SaaS in 2023
Defining your SaaS product strategy is the most important aspect of deciding to build something new.
It helps your entire team rally around a vision and a set of outcomes, making sure everyone is aligned in reaching those product growth goals.
But where do you start, how do you define it, and how do you take the steps to achieve it?
Let’s dive in 👇
What is a product strategy?
In the simplest of terms, product strategy is outlining the what, why and for whom it is you’re trying to achieve by building your product.
It helps define the problems you are trying to solve and helps form your product-market fit.
In product, strategy is made up of three components:
- Your product vision.
- Your objectives.
- Your roadmap.
Having a strong product vision is important as it helps keep your team aligned under a purpose, ensuring everyone is working together to achieve that vision.
Furthermore, it helps you explain to others (internally and externally) what the future of your company is, extending transparency across the board.
1.How do you set a product vision?
Roman Pichler suggests a product strategy should contain three key elements:
- The market for the product and the specific needs it will address.
- The product’s key differentiators or unique selling proposition.
- The company’s business goals for the product.
There are various formats and designs to help you build a solid vision, including the Lean UX Canvas by Jeff Gothelf and the Business Model Canvas by Alexander Osterwalder.
Company and product visions are meant to be inspirational, not detailed. This is a high-level document to give your team direction.
2. How do you create objectives?
Once you have outlined your vision, you can start extrapolating objectives from them.
There are two kinds of objectives – company and product-specific.
The main difference being the company-level objectives can be applied to all products, and the product-specific objectives are derivatives from the company objectives, distilled down to a more customer-centric or product-centric outcome.
The first rule of objective building: make your objectives quantitative
Objectives are meant to help you measure something, whether that be reducing or improving a metric. Objectives are never static, so if you’re aiming at “keeping” a percentage or a number at a certain level, all you’re doing is keeping track of a benchmark.
The second rule of objective building: make them outcome-focused
Outcome-focused objectives are specific and concise statements that state:
- what change is being made
- by how much
- and what is affected by that change
Clear, concise outcome objectives clarify expectations and can be used to determine progress towards your goal.
The third rule of objective building: set a key result.
A key result is not the same thing as a KPI (key performance indicator).
Key results help you focus on the outcome of the activities you will be undertaking. A KPI is used to measure the continued progress towards a defined performance measure.
This cannot be said enough: Outcome > Output.
Here are a few sample objectives and key results you might want to start tracking:
Objective
- Improve User Experience
Key Results
- Reduce usability support queries by 10% by Q3
- Increase visibility on videos and resources by 15%
- Decrease rage clicks by 50%
Objective
- Increase Membership Numbers
Key Results
- Increase new user base by 10% end of Q2 2021
- Expand usage of existing accounts by 5%
You will notice some key results are time-based. There’s been plenty of debate as to whether or not they should be – in my opinion, that is up to you.
That only thing I will say is that regardless of whether you choose to make a key result time-based or not, you should continuously go back and revise, update, and log how outcomes are being affected by the changes you make. Just because you’re no longer working on initiatives that affect that specific key result, it doesn’t mean changes aren’t still happening.
3. How do you create a roadmap?
I could write an entire post on this (as a matter of fact, I have!) but I’ll try to keep this a bit high level for now.
Once you have your vision and objectives defined, it’s time to start focusing on your roadmap.
If your vision outlines what it is you want to achieve, your roadmap outlines the steps you will take to achieve those things.
The first rule when building a roadmap: focus on problems, not features.
I can’t stress this point enough – your roadmap is not a list of features, it is a list of questions.
These questions should focus on the problems you could solve and how you might approach them.
Focusing on problems allows you to take a step back and see things more holistically. Instead of tying yourself to a solution, you’re giving yourself space to understand what that solution might look like.
For example:
Listing a feature: Salesforce Integration
Listing a problem: How can we support our users on Salesforce to integrate with our app better so that they can get insights on the information gathered in their CRM? As a result, allowing for some form of integration might help us expand revenue and offer more services.
The first option makes way for misinterpretation and – let’s call it, creativity on the side of the viewer. It leaves too much room for wrong expectations. After all, every person might have their own version of what a ‘Salesforce integration’ will look like for them.
The second option gives you more space to understand what it is you are trying to do.
You know you want to look into a Salesforce integration to solve a problem for your customers, which would also give you the benefit of more revenue. However, you’re not adding room for misinterpretation, if anything, you’re making it clear you will be looking at how you might approach the said integration.
The second rule when building a roadmap: only work on initiatives that meet your current objectives.
If you want a really solid product strategy that keeps your team aligned and focused, then don’t work on roadmap initiatives that don’t help you meet your current objectives.
If your teams are focused on decreasing churn and improving your product’s UX, don’t start working on initiatives related to improving your shipping ops.
This will not just add to confusion, but it’ll lead you to inadvertent feature bloat. And not just that, but because you’re focusing on things that aren’t currently a priority, you’re risking not meeting the objectives you’ve set, setting you up for failure.
4. Discovery and Experimentation as Part of Product Strategy
Giving yourself space to run discovery and experimentation on problems can help you reduce the risk of business failure.
That is, if you find out that a particular idea won’t give you the desired outcome you wish to achieve, instead of wasting time implementing it, as well as adding possible tech debt to your application, you have the chance to figure those things out before they happen.
If you’re new to experimentation and don’t know where to get started, I highly recommend Teresa Torres’ Opportunity Solution Tree. This framework will help you look at your ideas not in the sense of ‘good’ or ‘bad’ – but what gives you the closest result to your desired outcome based on the objectives and goals you want to impact.
5. Where to Start – Product Discovery vs Product Strategy
It can be tricky to define whether or not you should start with discovery or with strategy. How does one affect the other?
Moe Ali, CEO at Product Faculty, says that product strategy is more important than product discovery.
Moe brings up some really great points:
- A long list of features isn’t a strategy 👏
YASSSS!!!!!! Here here, cheer cheer! Moe hits the nail on the head! Focus on problems, not on features.
- Equally distributing dev capacity isn’t strategy.
Understanding capacity is execution, not strategy. Strategy is what, why, for whom. Execution is how.
- Good product strategy boils down to making trade-off decisions about where and how to compete.
And this is where your vision and objectives help you keep focus. Do not be reactionary to what others are doing, focus on what your vision is and what you hope to achieve.
But is it true that strategy is more important than discovery?
Well, it depends. (If you were waiting for me to say that, you’re welcome.)
John Fontenot, CPO @ Path2Product, says the most important thing is to define what strategy is, and follow it up with what type of discovery work you’re doing.
As John explained, there are three types of discovery work:
- Generative
- Evaluative
- Investigative
Generative user research should inform strategy, while strategy should inform evaluative and investigative discovery .
The most visceral example of why generative user research should inform strategy is in the case of early stage startups. If you haven’t clearly defined and properly framed the problem you’re trying to solve for users, then how do you properly come up with a plan to solve it?
Therefore generative user research must come first. The fact that it so often does not is a big reason why so many startups fail. But you could also apply this to established companies and attribute it to why over half of app features built are never used.
Product maturity and growth stage definitely feed into whether you’re starting with strategy or discovery, but it all leads to the same outcome – understanding what problem you are looking to solve and why.
How Userpilot Helps With Getting Feedback
As you’re defining your objectives and are looking for possible ways to solve a problem, Userpilot can help you run quick discovery and experimentation for you product. Run low-fi tests, ask your user questions, and set goals for your experiments to help you understand how you might best approach a problem.
Once you have gathered feedback and implemented a possible solution, keep your customers up to date, close the feedback loop, and look like an absolute superhero 🤩
