Minimize the cost of being wrong

Sten Pittet -

As you finalize your quarterly plans and OKRs, it is essential to include safeguards to make sure that you're on the right path. It's especially true if you have projects that will take months of development before reaching your customers.

The right side of wrong

There are 2 ways you can approach product development:

  • Your job is to find the right solution.
  • Your job is to be less wrong over time.

I'll argue that the second option will produce better results faster, and lead to a happier team.

Your market is always on the move. The best you can do is formulate hypotheses about what your customers want right now. And whatever answer you find might not hold true in a couple of months. It makes it really expensive (impossible?) to find "the truth". A team that wants to be right will waste a lot of time debating the details of their projects. It also creates friction as it puts team members against each other as they try to figure out who's got the answer.

On the other hand, teams that embrace uncertainty can move faster:

  • They'll be better at thinking in terms of probabilities.
  • They'll embrace experiments to fill gaps in knowledge.
  • They'll ship early and iterate to improve their solutions.
  • They'll see divergent opinions as something interesting to explore.

"What if we're wrong?" is a crucial question, and you'll want to make sure that the answer is not that your business goes to the ground.

3 ways to minimize the cost of being wrong

Here are 3 small tips to help check that you're heading in the right direction.

Add validation goals to big projects

Some projects are hard to break them into smaller pieces. It may take more than a quarter before you can put it in the hands of your users. You might end up with an OKR that looks like "Ship the new billing system".

But, what if you're wrong? What if the choices you've made are not what your customers are expecting?

A simple safeguard would be to add UX testing and customer interviews as sibling goals for the quarter — even if you've already done some research. Use that time to refine the user experience and figure out the edge cases while your dev team is working on the infrastructure.

Make your development milestones impact-based

Milestones should be based on results rather than releases. In our billing system example, it's not enough to say "the new plan management system is shipped". A better milestone should say something like "the plans X, Y and Z are created and tested". What matters is that you have proof that it works.

It emphasizes the outcome rather than the feature. It will help the team avoid unnecessary development, and it'll be easier to consider alternatives to deliver the same impact.

Track progress on your plans weekly

If you can only change one thing, I would start by tracking progress on your strategy every week. The faster your feedback loop is, the easier it will be for you to understand if you're trending in the right direction, or if things are getting riskier.

Weekly check-ins will allow your team to:

  • Keep in mind the top priorities.
  • Weed out bad goals and OKRs quickly.
  • Mitigate risks early.

What's really important is for you to treat your strategy as something agile. Your quarterly plan is a best guess of what will improve your business — you should keep track of it and refine it as the quarter goes.

Of course, Tability can help automate that process (it's pretty good!), but you can also get started with a simple spreadsheet.

What's next?

Take some time to look at your quarterly plan, and make sure that you have ways to mitigate the risks of large projects. Get validation early, and often.