Features are a starting point

• 3 min read

Features are a starting point, but what customers really care about is what those features can do for them.

Features are a starting point, but what customers really care about is what those features can do for them.

A quote from the book Obviously Awesome, which neatly sums up a lot of what is wrong with many product teams. We’re so focused on ourselves, our processes, and what feature to build, that sometimes we forget about what really matters: solving a problem for users.

While this statement seems so obvious, why is it that many product teams still fail to organise themselves around the right things? Why do so many product teams still optimise for output instead of outcomes?

The answer to this is more complex than you think, and while most individuals may be able to recite the right answer in theory, the organisational systems we create are working against us, and most don’t know why.


First we need to examine how planning happens within the company. Whether you’re using OKRs or a different style of planning and goal setting, the principle is the same:

  • Leadership should be defining the vision and the metrics (where we are going and how will we know if we are there) but never defining how we are going to get there.
  • Teams should be figuring out how to get there in the best way, experimenting, executing, and iterating.

Many times you’ll see leadership use goal setting as a sort of todo list they give to the teams. This usually happens either if the leadership team doesn’t understand how to plan properly, or if they wish to micromanage. Either way, something is terribly wrong.

Bad planning like this leads to a disconnect between product and users because you’re removing or seriously hindering the tight feedback loop with users that product teams should aim to create. You’re effectively giving the roadmap to those who are most removed from users, or trying to guess what is valuable, without having found the answers yet.

Other times, you’ll see the teams themselves creating the OKR ‘todo list’, which gets passed up to leadership for sign off. This is micro-management in disguise. Why does this happen? Let’s talk about success and failure.

Success and failure

The definition of success and failure, and the perception of these topics within the organisation, has a monumental impact on how product teams plan and execute work.

In many product teams, success is marked by launching a feature or finishing the tickets in a sprint. While this is undoubtedly satisfying, and gives the awaited hit of dopamine, it is also forgetting the point: customers care about what those features can do for them.

Shipping the feature is the first step toward an objective, but it’s just that: one step. Features are a starting point.

Success comes from achieving the desired effect on or for the user, not simply getting the feature into their hands. The conversation doesn’t stop when you’ve shipped; it continues for the lifetime of the user.

We need to change the definition of success. Success is when the feature we shipped had the desired effect on the user.

Perhaps less obvious, though, is the perception of failure. While we all like the sound of innovating and fostering crazy-but-maybe-impactful ideas, organisationally we are usually afraid of them. Structurally, we hinder them.

When organisational systems are working against us, and there is an inherent fear of failure, then teams will act in a manner of self preservation. They will set goals that they know they can achieve, and goals they can easily explain to leadership. Goals will no longer be ambitious or innovative, because by definition, you need to take risks to innovate.

Quoting Christina Wodtke from her book Radical Focus, "OKRs need to be hard goals. The kind you only have a 50/50 shot of achieving."

In order to drive a truly innovative product, you need to accept the fact that there is a non-trivial chance of failure — probably often — and deliberately set up your organisation to support and celebrate that.

Calculated risks should be built in to planning conversations, and even pushed by leadership if the plans are too conservative. Failure should be seen as one iteration but not the end of the road. Failure should be showcased and talked about, as a lesson. Teams should fail fast with deliberate experimentation and a careful watch of important metrics.

In fact, we should not even call it “failure” anymore. When you deliberately set out to learn if something works or not, with the risks being calculated, then failure can only mean that you didn’t learn.

Without a senior leader driving this culture and style of planning, you’ll only ever see the conservative goals that look like todo lists.

← Focus

Subscribe to Shane Neubauer

Subscribe to the newsletter and unlock access to member-only content.

You've successfully subscribed to Shane Neubauer
Welcome! You are now a Shane Neubauer subscriber.
Welcome back! You've successfully signed in.
Success! You are now a paying member and have access to all content.
Success! Your billing info is updated.
Billing info update failed.