Moving Fast Whilst Heading In The Right Direction

If you work in a startup, you may be familiar with that slight sense of unease that accompanies you when working on a product. That muffled voice at the back of your mind questioning whether you’re doing the right thing.

But the frenetic pace, the endless list of tasks, the panicked, slightly maniacal look in everyone’s eyes as they hurriedly get as much done as possible — that muffles the questioning & the criticism.

Startup culture tends to foster speed over reasoning, so we rarely stop to ask ourselves:

“Are we really building the right thing?”

In every company, there exists a certain tension between speed & good decision-making.

Move too slowly & you’ll get killed by the competition.

Move too fast & you’re likely to end up building features — or an entire product — that provides a solution to non-existent problems.

So what’s the right balance?

One approach to solve this problem is to differentiate between what Jeff Bezos, CEO of Amazon, terms Type 1 & Type 2 Decisions.

In short, when kicking off a project or creating a task ticket for the backlog, everyone must ask themselves:

“How easily reversible would this be?”

 Type 2 Decisions

Most large organizations embrace the idea of invention, but are not willing to suffer the string of failed experiments necessary to get there. Outsized returns often come from betting against conventional wisdom, and conventional wisdom is usually right. Given a ten percent chance of a 100 times payoff, you should take that bet every time. But you’re still going to be wrong nine times out of ten. — Jeff Bezos If it is likely to be a small project taking maximum 1–2 days & including 1–3 team members, then we define it as a Type 2 Decision — something easily reversible, that doesn’t need too much planning, that will show clear results very quickly & allow us to adjust accordingly.

For such tasks, it is a simple case of filling in our Task Template on whichever project management software the team is using (Jira, Github or Trello) to clarify the nature — and necessity — of the task for the creator & the team members involved.

This allows us to move quickly, whilst also ensuring there is a framework for integrating tasks efficiently into the product development cycle.

The objective is to move quickly & validate along the way. If the idea works, great. If it doesn’t, learn from it & move on. A rapid development cycle allows us to test more ideas faster, so we can find the 1/10 that creates a big, positive impact for users.

Type 1 Decisions

If, on the other hand, a task is likely to be difficult to reverse, involving a lot of team members & a week or more of team work, then it is defined as a Type 1 Decision.

Such decisions should not follow the typical startup approach of focusing on just getting shit done in a mad rush. In such cases, ensuring you are building the right thing is far more important than just building something.

If you build a large feature that does not solve a problem for your users, you are not only wasting weeks of your team’s time. You are also clouding the company vision, building up technical debt & risking your team’s motivation & momentum.

When dealing with a Type 1Decision, it is essential to follow a proper Design Process.

I have written about Design Processes elsewhere, but in short it constitutes:

 The foundations for a good Design Process

1. Discovery

Discovering an important user need from quantitative and/or qualitative user data.

Example: if your analytics data show only 20% of users complete ‘Onboarding’ on your product, then that is a major blocker in your funnel you need to address.

2. Analysis

Deep-diving into that specific problem to discover further insights to better define the problem.

Example: you conduct user interviews & user testing related to ‘Onboarding’, which reveals a couple of specific problems with your current ‘Onboarding’ flow.

3. Design

Producing wireframes with stakeholder input to then convert into a prototype to test on prospective or current users, providing you with some feedback on the proposed solution to improve it before committing to building it.

Example: Testing out a new onboarding flow on users with a prototype & iterating a number of times to ensure they are able to complete the flow.

4. Implement

Commit to a final UI that developers are able to implement.

Example: Handing over final UI to developers for the new ‘Onboarding’ flow with clear specifications & complete access to design assets.

Differentitating between Type 1 & Type 2 Decisions provides you with an explicit framework for making product decisions:

It allows you to move quickly on product changes that do not need a huge amount of deliberation.

To thoroughly focus on the problem before building a solution when dealing with larger product changes.

And cuts out all the discussion & miscommunication that usually comes in between.

This allows you to focus on what matters:

Delivering real value to your users as quickly as possible.