I enjoyed reading shape up. I have had to introduce it slowly to the team I work on.
Certainly I am breaking some rules here but I started with a “half pitch”. Defining only the problems to be addressed and the scope of the project.
Curious to know if anyone else has done this, prior to jumping into the rough solution space?
PS. I once think I read in shape up where ryan said the best way to articulate a problem is through a customer story. Or something along those lines. I one hundred percent agree with this, and it has been a powerful tool.
I sort of lean on Ryan’s chapter on pitches and believe that a problem-only pitch is not a pitch. Without appetite, solution, et al. you have no guardrails to explore the problem.
That said, we do shape time-boxed work for problem-space research, e.g. “Interview 3-5 customers on behavior X to get signal on Y” and the “solution” is usually a set of insights or recommendations to inform future bets/pitches. (I’m lucky to have a UX-R person on my delivery team.)
But I think that’s the exception. Most delivery teams don’t have an embedded UX-R, so all that problem exploration should be done by the shaping folks, prior to crafting the pitch. Just my two cents.
Anyway, my gut says if you’re new to ShapeUp like me, I’d try to stick to Ryan’s format for pitches early on and tick all those ingredients for what defines a pitch, if only to acclimate your team to those concepts. Best of luck!
Thanks for your response. I agree that a pitch without an appetite and solution is too vague and sort of defeats the purpose.
Interesting that you bring up UXR, as I am the dedicated UX-R on the team. My approach with a problem only pitch has been to sort of try to gather help for defining the solution.
I am confident in the problem definition, but the daunting bit for me is defining a solution that is less than it could be if that makes sense.
Open to any more comments and feedback you may have!
I think what you’ve got with defining the problem is an important part of the pitch, so I think instead of viewing it as doing as “half-pitch”, rather take the perspective of you’ve got half a pitch done - now you just to finish it with the actual shaping with.
At first I thought problem definition was part of shaping, but Ryan informed me I was wrong on that. Before you start Shaping, you need a well understood problem and an appetite. Those two things feed into Shaping efforts, but getting them is not the actual Shaping work. So it sounds like with where you are at, you could set an appetite for solving the problem and then being Shaping (a solution).
In your case, are you wanting to pitch a solution or rather pitch a problem as a shaping candidate, rather than a betting candidate? Hopefully that makes sense and helps
Hmmm good clarification! I am certainly pitch a problem as a shaping candidate! … since the work is not fully shaped it cannot be a betting candidate, because we don’t know what we are betting on, and what is the downside risk!
Thanks for the clarity. Since your commitment to the delivery team is less than 50 percent, I’d follow Aylon’s advice and keep your research work outside the delivery team’s cadence. Just support the betting table and delivery-work shapers with your research insights and recommendations.
The only reason why our team shapes research work at all is because we follow Teresa Torres’ continuous discovery model, so part of product/service iteration is CD work happening in the cycle, done by the delivery team.
Agree with the consensus that appeared here. I would summarize it like this:
If you’ve identified a problem, but you don’t have a solution yet, that is an input to the shaping process. A pitch, on the other hand, is the output of the shaping process. A pitch has the key points of a solution in it so the team doesn’t have to do discovery.
@jordan It’s a communication piece, so it’s all about what makes sense and helps the other people who read it to judge why it matters, whether they should bet on it, and how to evaluate the solution.
