I wrote a variation of this for the various product teams at Whispir recently and then as fate would have it, a friend I know reached out to me on LinkedIn asking the same thing — so I thought I’d share the same instructions with the world I gave everyone at the office.
This process allows you to go from “I have no clue what to do”, “to we should do this!” with very little effort but a huge amount of diligence and thought, and you can do it in 15 minutes if you have access to all the research already.
It describes the ideal situation to work with teams to ideate solutions and provide a final recommendation on what to build. Whispir product teams use the Circles method to get to final recommendations. Circles is a product framework I learned about from some product managers at Google.
Being able to run through the Circles framework quickly is one of the tasks we have product managers perform in their interviews. It’s a great way to see how judgment can work under pressure and how people evaluate tradeoffs. To do this on the fly is a keystone habit for good product management at Whispir.
This article explains how product managers should facilitate ideation sessions step by step. This process allows the most collaboration and inclusion from all members of the cross-functional team to arrive at a place where the ideas meet four basic needs.
- Viable (represented by the product managers understanding of the market and the business context)
- Desirable (represented by the product managers understanding of the customer and what they want)
- Feasible (represented by the engineers understanding of our technology and capabilities)
- Usable (represented by the product designers understanding of user-centric design and how the customer might interact with your idea)
At Whispir, we’ve gone a step further and actually outlined thresholds for each one. For instance, we remove the subjectivity of what desirable means by instead saying that at least 60% + of our ideal customer personas must express significant interest and willingness to pay for an idea to call it desirable.
Step 1: Help the team comprehend the situation 🔗
Teams often lack context. So it’s important to help them understand the problem space and what’s happening with the market. The product manager should provide this information to the team to help guide them towards the ideal scenario. You want to focus on 4 things. What is the problem we’re here to solve? Who has this problem? Why do we need to solve this problem now, and how we might tackle it? Good product teams ask lots of questions. So if there are no questions here, make sure you extract them to ensure everyone fully understands the process.
Step 2: Who 🔗
The most critical part of any software company is being crystal clear about who you are solving the problem for. At Whispir, the only person we are building a product for is the ideal customer persona (ICP), a term we use a lot. Re-clarify who this is and who it is not.
Step 3: Report customer needs 🔗
Customers have real needs and problems — and we are here to solve them using the software. That’s our job. So, the product marketing and product management teams constantly discover these needs through surveys and interactions, and to document these we use something called jobs-to-be-done (JTBD). We document these formally so they are always available to see in confluence.
Next, go over the primary jobs the customer is trying to get done with the team and write them on sticky notes or on a whiteboard.
Step 4: Cut through & prioritize needs 🔗
The product management and product marketing teams will have collected data on just how important each job is. We plot these on JTBD maps and in most cases, this will already be done before the session.
We plot the jobs on two dimensions.
- How satisfied customers are with completing this job with our product (or the competitor’s product) today?
- How important getting the job done is to the user.
If you focus on the bottom right of the matrix, you will build a product that attracts users to the platform with little energy required to persuade them. Think ‘selling bottled water in a desert’ and you get the drift.
By focusing on that bottom right-hand area, you can build a company that competes with bigger competitors with fewer resources simply by prioritizing more aggressively around unmet user needs.
However, when it comes to table-stakes features, there may be a situation where most people are satisfied with a feature like “Forgot password” but the job doesn’t seem that important. When you don’t have that feature, the absence will create so much friction and detract from the experience that they might not be able to extract value from the features in the bottom right-hand corner. So, sadly, it’s a balancing act. You have to do a little of both.
If you want to know if you have too much of one or the other, you can use something called a value matrix. It plots out two dimensions, value, and a customer’s willingness to pay for that value. I’ve put an example below.
Trade-offs matter. So focusing on a balance of competitive functionality and table-stakes functionality is important. But focusing too much on one area is a dangerous position.
Step 5: List solutions 🔗
Next is the ideation part of the story. Pick the job-to-be-done you are trying to work on and ask the team to list a range of possible solutions.
Very Important: Much like a company has values to guide its hand in how to create thriving cultures, products also have values. These values (or principals) give the product a unified personality and solidify a feeling that the product is designed in a consistent manner. Whispir has 5 product principles.
Remind the team of them and help them look for opportunities to embody these principles throughout the ideation process.
Step 6: Evaluate trade-offs 🔗
The best way to evaluate trade-offs is to look at two dimensions. What is the impact of this idea on our objectives, and how complex would this be to build?
The complexity dimension is often the part the engineers contribute to the most and is where we learn if an idea is feasible or not. Sometimes if an idea is so critically important, it still may be worth pursuing, but only you will know that.
The designers here also provide a key data insight on usability. Often times just because we can build something quickly, it can lead to a situation where the usability deteriorates so much that the overall experience impacts the user to the point where the product loses material value — especially to first-time trial users, and for a SaaS company this can have real financial impacts.
To help visualize this, you can plot each idea on an impact and complexity matrix.
You want the teams to have debated these concepts at this point and argue the trade-offs through the lens of the objectives. It’s really important you stress the importance of goals here. You can argue a case in various directions if the goals aren’t clear and the goals constantly keep you focused so bring them up constantly.
What if two ideas sound good? 🔗
If the idea is a case where several ideas make sense, this is where experimentation and testing with users can help inform the idea. Don’t be afraid to test multiple ideas with users. It is part of how we learn what to build.
Step 7: Provide a recommendation 🔗
Finally, make a decision. Once you’ve made this decision, the design team will work out how to make this idea usable for the customer and will begin the design phase of the idea.
When should you perform this ceremony? 🔗
This kind of work falls within the discovery track of software development (Learning what to build) at Whispir.
How often you perform this function will come down to your judgment. You don’t need to perform this level of ideation for small things like “Forgot Password Reset features.” Instead, use this as a way to mine creativity from the team where many options may be suitable.
Usually, I’d expect every team to at least perform this process once every planning increment. (We use a modified version of SAFe) so tend to plan in 10 week planning increments at Whispir.
As teams perform this activity, once you know what to build, the idea often migrates into the delivery backlog.
For larger ideas, it is worth performing this ceremony well ahead (maybe even an entire planning increment ahead of time) but for others, you might be able to perform it and have it actioned in the next sprint. In the above example, you can see the first idea (intelligent message designer) goes through this ceremony in PI1 but only gets built in PI2, whereas premium components seem to get worked on nearly a week or so after you do discovery on it. It will come down to your own discretion as a product manager to see what works for you.
