How do you get stakeholders to buy into variable scope product pitches?

When you're starting to adopt Shape Up at your company it's common to feel like the concept of fixed time and variable scope is daunting to both stakeholders/leadership and builders:

• Stakeholders are unsettled by the fact that they don't know exactly what will be shipped by the end of the cycle.
• Team members can feel pressure to perform and struggle with the idea of delivering a fraction of the intended functionality.

While team members have to get accustomed to this new way of working from the traditional approach they've been used to, the pitch template from Shape Up misses an essential ingredient to getting stakeholder buy-in in companies where they're 1 or 2 degrees off from being deeply involved in a product's development.

When the shaped pitch is completed, the flexibility that's provided to engineers and designers can be overwhelming to stakeholders because imagining the final solution is difficult through primary functions and affordances from the solution.

Moreover, it doesn't explicitly state what the business stands to gain for the appetite set to develop the solution. It might even be open to interpretation as they read through the pitch's problem and solution sections causing anxiety.

Your solution may be to include a high-fidelity mockup to make the shaped work more predictable to appeal to their imagination, but this will tip the balance of the shaped work being too prescriptive, giving the impression that you're telling engineers and designers what to do. As a result, they have little room to make trade-offs and make them feel as if they don't have ownership of the work during the build phase.

To err on the side of keeping the scope variable/flexible as per the Shape Up way and communicating to stakeholders that the shaped work is aligned with strategic objectives, here's what you can include in the pitch when its time to help them make a confident bet:

Include a section about the hypothesis that changes the current state of the user before going into the problem definition:

• We believe <this feature/solution/capability>
• for <users>
• will result in <the outcome (change in your user’s behaviour).>
• We will know we have succeeded when <we see x measurable signal.>

You can utilise the job story as a baseline to frame this section but in the language that your stakeholders can understand.

Let's try put it into practice

Imagine we're a medicine delivery startup that allows adults caring for elderly parents with noncommunicable diseases (NCDs) like diabetes to order, track, and manage their parents' medication needs from a remote location.

After shaping the demand side, you've found signs of struggle for this group of people when it's time to pay for the prescribed medication. Particularly relating to their budget constraints and brand preferences.

We then start shaping the supply side with a "flexible pricing feature" that will enable these users to pick and choose medication brands depending on their budget and preferences apart from what the doctor recommends.

The above hypothesis then becomes:

• We believe that developing flexible pricing
• for adults who take care of their elderly parents with NCDs
• will result in increased ordering of alternate medication brands that isn't in the prescription.
• We will know we have succeeded when at least 70% of our customers order medication that isn't the same as what's in the prescription within 30 days of launching.

By including a measurable success signal and the state change of the user, you'll be able instill confidence in the stakeholder that the pitch is worth betting on without having them dig around to find out if the effort spent is going to be worthwhile to the business whilst keeping it customer centric.

After the product or feature has been delivered to users, you can submit an outcome report between 30 and 60 days after launch (depending on the success signal's parameters). This emphasizes whether the previous cycle's bet paid off (or not), and it allows you to objectively measure the impact of that cycle's effort.

Completed and Under Evaluation

Your bet on Cycle X: Flexible Pricing

• We believe <this feature/solution/capability>
• for <(x number of y users)>
• will result in <this outcome (measurable change in your user’s behaviour).>
• We will know we have succeeded when <we see x measurable signal.>

Results:

(Qualitative and/or quantitative data for users and business impact)

Conclusion:

• Did the results match your hypothesis? Y/N
• Did the results contradict your hypothesis? Y/N
• Are the results inconclusive? Y/N

Next Steps:

What are we doing, if anything, to improve the results of this release?

The use of this section in the pitch, as well as the post-launch outcome report, will allow stakeholders to gradually become more comfortable with Shape Up and believe in the process without having to ask them to believe you or to just trust the process.

References:

• Matt Lane's awesome pitch template
• Shape Up by Ryan Singer
• Demand Thinking Episode 2
• Building a minimum viable feature