[CHEAT SHEET] Making Valuable Things

Tal Raviv
4 min readApr 15, 2019


I’ve helped make a bunch of things in my life. Some were more valuable, some less valuable. Some took way too much time, money, and collateral damage to figure out the difference. Sound familiar? There’s a lot of frameworks to solve this:

Lean Startup, Customer Development, SVPG/Inspired book, Paul Graham essays, Design Sprints, Reforge course, NFX Guild, MIT 6.033, Traction book…

Whether startup or new feature, they all divide into two activities:

This is my personal cheat sheet for all the tactics that fit into those two activities. It’s a cheat sheet, so I’ve kept it succinct.

The structure of this cheat sheet also happens to be a good way to communicate an initiative: Hypothesis/Customer/KPI, followed by Idea/Risks/Validation strategy. You may have heard this called an “Opportunity Assessment” or “Canvas” and so on.

Creating value starts with a question. If you’ve been handed a hypothesis, hunch, objective, or mission, think of the underlying question.

  • What do people want from an X?
  • What are the blockers for X?
  • Why is X problem happening? What’s wrong with X?


“In the weeds is where it’s at.”

Buster Benson (Amazon, Twitter, Slack, Patreon)

Below are ways to get in the weeds:

Each of these tactics is severely limited. Remember the parable of the blind men and the elephant. Don’t lean on one source as “truth”— get a healthy mix.

“Even after interviews with potential users or experts, observations, market analysis, and so on, I never feel or proceed as if I know anything.“

Ursula Shekufendeh (Appfolio, Copper, Patreon)

Note: Should I prioritize problems? It’s important to focus, so roughly prioritize. With so much uncertainty, the emphasis is on “roughly.” I look for a bottleneck, i.e. the problem that’s holding up all the other problems.

Note: Should I define success? Consider explicitly defining and measuring what success looks like. It helps when you’re far from the actual thing and won’t directly feel the pain of failure. Defining success is also for being honest and credible with yourself, leaders, investors, and keeping a team on the same page. Remember to differentiate between a business metric and a value metric. That said, remember metrics aren’t perfect, so don’t go overboard.

Since you’re deep in the problem, your team probably has a bunch of ideas by now.

Note: Should we brainstorm? Sure, with good principles, but don’t make it the main event. Immerse people in the facts and hypotheses. Most value comes from straightforward solutions to well-defined problems.

No matter how brilliant the idea, chances are it ain’t gonna work the way you thought on the first try. Here are all the synonyms I’ve heard for “risks”:

Weak links, question marks, uncertainties, blockers, bottlenecks, assumptions…

You can also see each risk with its corresponding list of tests to try.

There’s many reasons an idea might fail, listed below. It’s important to prioritize your risks. So many people waste time working on the wrong risk (e.g. focusing on technological risk, when the real weak link is positioning or acquisition).

Look for the bottleneck risk, i.e. the risk that casts a shadow on all the others. Alex Furmansky eliminates risks by asking: “What aspects are you not the first to have done?”

Test it in the cheapest way that can conclusively reject or modify your thinking.

Should we prioritize our tests? Yeah, but only roughly. The real key is to make your tests so cheap that you try a bunch.

What happens if a test works? No test can prove success; it can only poke holes. Go back to the drawing board as many times as necessary. When feedback reaches diminishing returns, raise the stakes, or move to the next risk.

With each test, you gradually increase your confidence that you’ve built something valuable.

How ratcheting up might look like. It’s a tradeoff of speed vs. exposure to risk — and that’s your bet to make.

Sometimes this process happens quickly, sometimes gradually, and sometimes with no testing at all. It’s a tradeoff of speed vs. exposure.

Test too much, and you might miss opportunities. Skip ahead, and you might stumble on obvious gotchas.

You could “launch faster,” though you might miss obvious risks at the foundation. I’ve made this mistake enough times.

I say move gradually, but not slowly. Remember this truth:

“Every successful complex system is found to have evolved from a successful simple system” — John Gall

With high enough confidence, it’s time to take things all the way: expand across segments, devices, security, localization, edge cases, etc. This is where the experts take over: engineering, product marketing, operations, etc. There’s many words for this, though I like the term in Inspired: “Delivery.”

Use the same principles of keeping risk low when you enter new territory. And start the cycle all over.

To quote Bill Burnett from Stanford: “It’s simple: get curious, talk to people, and try stuff.”

Thank you to Marty Cagan, Buster Benson, Erin Boyle, Ursula Shekufendeh, Noga Raviv, Alex Furmansky, and Tyler Palmer for their candid feedback.



Tal Raviv

I love data, I love people, and I love being proven wrong by both. Product at Riverside.fm, ex-AppsFlyer, Patreon, Duckduckgo, Wix

Recommended from Medium


See more recommendations