Category: Product Discovery

Product Toolkit: Quick Proposal

Product Toolkit: Quick Proposal

(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!

Here’s a Google Doc Template if it’s helpful!

Don’t Taste One Coffee

Don’t Taste One Coffee

Did you know I had a whole career in specialty coffee before I became part of the tech industry?

It’s true – I trained hundreds of baristas, some of them competitors (barista competitions are a thing!), opened a number of cafes, developed a whole multi-course curriculum, I also kind of interestingly in retrospect did some product work with muffins?

One of the most memorable aspects of that time in my life was buying coffee, by which I mean, working with importers and exporters to source the green unroasted coffee to bring to the States, to then store, roast, sometimes blend, and serve in the cafes.

There are a whole library of ways that you can try to ensure taste (at a given price and availability) in the cup through the buying process. There’s a Sommelier type test for folks who do coffee buying professionally (which I did not pass by the way!) One of the most common tools in the toolbox is an exercise called cupping.

Cupping involves standing at a table, usually a very long table, where there are a collection of little groups of cups (the standard for professional buying sessions is 5, but I’ve been at tables with 3 or 4 cups per group, like in the image above), with each group holding a particular coffee from a particular farm. You might be tasting fifteen coffees, which would mean fifteen little groups around the edge of the table. Then, you and your colleagues and partners walk around the table, use your individual spoon to taste the different samples and different coffees, take lots of notes, and decide what fits your needs for the coming season.

Imagine instead, packing your bags, flying to Guatemala, taking a drive into the mountains, roasting, grinding, and setting up a single cup of a single coffee, giving that one lonesome sample a try, and your import partner turning to you and asking, “Well, should we buy it?”

Even if you’d tasted hundreds of coffees in your life, it would be incredibly challenging to consistently make the right decision in that moment.

Humans are really good at comparing. When we have the chance to assess multiple options, in real time, all together, especially in discussion with others, we are much more successful when we have a small number of things to compare and contrast to one another, rather than having a single yes-no binary choice.

So we never only try one coffee. You try lots of coffees, and you keep trying them as they cool, to help get as much information about the different options, the trade-offs, and guide you in making the best choice you can.

The thing is, this is also true for making decisions in other fields, especially in Product, whether prioritizing a feature or making a whole roadmap, or hiring onto your team. You will always make better choices when you give yourself the space and process where you consider and discuss alternatives and the trade offs between them.

Something happens in the process of discussing trade-offs – it forces you (and your colleagues!) to get really clear on your thinking, and it can help draw out benefits and drawbacks that wouldn’t have arisen if you’d only tasted the One Coffee.

Teresa Torres (absolute luminary, her book is a must-read imo) outlines a great way to do this in the Opportunity Solution Tree exercise. If you give that approach a try, you’ll have lots of options to consider!

If we’re talking about the Ideal Platonic Product Organization (which doesn’t exist, by the way!), following our successful Opportunity Solution Tree exercise, we’d produce a ranked list of these potential opportunities to prioritize, and then we’d leverage our reliable, fast, and effective experimentation framework to run tiny inexpensive experiments to determine which possible direction would go the best with your customers and infrastructure, and then execute on that opportunity.

I can’t speak for other fields, but in developing software, Only One Coffee can sneak up on you.

“When can we schedule the Anti Light Particle Beam feature?” … when you hadn’t even heard about the Anti Light Particle Beam feature!

“Nautical Cloud Experience says we need to build the Zoidberg Platform v3 out by end of March to unblock their P Zeroes.” … but Zoidberg v2 was never even completed!

In situations like these, it’s incumbent on the Product organization to say, “Wait, hold on a minute, let’s think about what our alternatives are,” and then do so in a structured way. Remember, you always have the choice to do nothing! Between the proposed Single Coffee, and the evergeen Do Nothing, if you come up with only one or two other possible paths to a solution, you’ll already be in much, much better shape.

You won’t always get the chance to go through Discovery exercises, and you won’t always have the experimental infrastructure or organizational support to run lots of iterative experiments. But you can always ensure that you’re considering alternatives, and giving yourself and your firm the best chance at building the right thing.

The most important thing a Product organization does is avoid building The Wrong Thing. Never taste only one coffee.