(if you’re just looking for a link to the QP template, here it is!)
This post is the first in what I hope will be a recurring series where I share some of the tools that I use, and work with my team to develop, in our product practice. In this way I hope to show our work, make the role of the Product org more transparent and accessible, and maybe help folks find success in their professional life (or maybe personal life, who knows!)
You’ll hear a lot of opinions about the role of Product Managers. They’re probably all right in their own way. Realistically, different teams will leverage the title “Product Manager” in really different ways. Sometimes it’s predictable; Product at a seed stage startup is going to be incredibly in the weeds and will wear about thirty hats. Product at a big legacy company needs to think more about organizational topology and cross functional buy in.
This is even setting aside the great controversy of “Product Work,” as in, “We’re not even spending our time doing Product Work,” which is a whole different and interesting conversation.
I’ve settled on a position, as one must, in these matters. It’s my sense that the most important thing a good Product team does, is they work very hard to avoid building the wrong thing. There are a lot of tools and approaches, mindsets and strategies, but a good Product organization should mostly be focused on maximizing a firm’s opportunity to get it right, and the fastest and most effective route there is to minimize time spent building the wrong thing.
There’s a lot written about Product Discovery (there’s even some right on this blog!) – if you’re curious more generally about how to assess opportunities, talk to customers, and why it’s important, I recommend starting with the singular Teresa Torres and her excellent book, Continuous Discovery Habits.
Discovery within an organization, finding ways to gain a better understanding of what’s going on within your company, how to get things done, getting sufficient input from the right folks, is a key input to Not Building The Wrong Thing. The thing is, it can be quite a lot different from interviewing customers and reviewing AARRR funnel exercises.
For one thing, these people have a fundamentally different relationship with you than your customers do. Ideally, they have an actual relationship with you! You work together, you have shared interests and (hopefully!) are aligned on what it means to find success in the upcoming quarter, year, and so forth.
They’re also busy, and unlike your customers, there can be a lot at stake in their interactions with a product person, even one with great intentions, even one with whom they’re aligned. Seasoned professionals are also very aware of the challenge of building things within larger companies, and the amount of uncertainty and potential risk to their own careers, especially around taking big swings.
There is a pattern of behavior here that I have seen myself, and have heard discussed many times in product circles, where it feels like nothing can gain purchase on the actual backlog of real, living engineering and operational teams. It feels like you’re stuck in a cycle of meetings, discussing at a high level the trade offs, propriety, the sensibility of a given possible piece of work.
You’re stuck in Abstract Land and just want to clear the air, and get something moving.
(There’s a blog post here about, platform product teams serving the role of uncertainty sponges, maybe?)
It’s not that your partners and stakeholders are doing anything wrong, or malicious – in fact, like you, they’re behaving in accordance with their rational incentives. It can be challenging to get out of high level abstract space and down to decisions, in part because:
- Folks don’t want to get it wrong: the fewer calls you make, the easier it is to avoid getting it wrong
- The abstract space is easier to be misunderstood / misaligned: if you and your colleague are saying things that are sort of aligned, in the fuzzy abstract, that’s fine.
- Folks don’t want to give direct feedback to a colleague. It’s much easier to correct a representative from a company you pay for a product from, than someone you might work with or need help from in the future.
One way to get out of this space is with a Quick Proposal. A Quick Proposal is a tool in the product toolkit that leverages one of the fundamental laws of the internet:
“The best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.”
Cunningham’s Law
A Quick Proposal is just that – a short written summary that offers your partners and stakeholders a chance to correct, update, and provide feedback on a document that takes a position, rather than staying in an abstract space.
Features of a good QP:
- It is one page long, and dated
- It is written in under 20 minutes
- It is in a format that everyone at your firm can access and comment upon
- It contains a brief round-up of what is known about the space under discussion
- It links out to other existing documentation, research, data, etc.
- It has a section called “Recommendation” which contains your best bet for the next action to be taken given the discovery and discussions that have occurred.
While a QP can help to spur action, it isn’t necessarily meant to be acted upon – it’s meant to:
- Capture your best understanding of a situation in as specific terms as possible
- Create at least one possible recommendation for next steps based on that understanding
- Generate a target for stakeholder feedback that isn’t another person, but a document
The way to use a QP is to present it as a loosely held summary – not, “I believe this is what we should do next, what do you think?” but more, “We have a lot of threads here, so I’m taking a crack at getting everything together. Does this look right to you?”
I’d also recommend when requesting feedback that you ask specific, relevant people directly, you provide a date by which time you’d like to make a decision, and you extend the offer for feedback to anyone else they’d recommend as having a voice in the matter.
A QP sometimes ends up being developed into a go-to-backlog type document (a One Pager, a Product Brief, a Product Requirements Document) but it’s real capital-J Job is to get your group and project out of the strategic stratosphere of Abstract Land and down to tangible discussions of what to do, how to do it, and when it can be scheduled, or, in the pursuit of Not Doing The Wrong Thing, perhaps it is set aside for other, more appealing opportunities; that’s also a win!
Simon Ouderkirk 