Falling in love with the product

As a product owner, it can be dangerous to fall in love with your product…

That might seem like a strange thing to say. Most product people (myself included) tend to get very excited about the product they are building. Why then, could all this enthusiasm be considered dangerous to product success?

‍

The key to this question lies is how we define the word success.

‍

Product-focus in action

‍

Imagine a scenario where a product team manages to build the ultimate vision of their product, with all the features they hoped to release, on time and on budget. A few months down the line, they admit that users simply are not engaging with the product. The team have run out of resources to make changes. They’re forced to call it a day and retire the product.

Although the team executed their plan perfectly, they did not succeed. To borrow a quote from Eric Ries, they had, in fact, “successfully achieved failure.”

This is all too common for teams who focus too much on the product and not enough on user needs and business goals.

‍

‍

Succeeding from the start

‍

Whether they’re based in a startup, a multinational corporation, or a not-for-profit, no product team sets out to create something that fails to deliver what the organisation defines as success.

The difference between an effective product team and the example above is that effective teams set out with a clear vision of what that successful end state looks like, for both users and their organisation.

For a startup, success might be getting to an IPO within five years. For an insurance firm, success might be improving retention of their existing customers. For a not-for-profit, it might be to reduce homelessness in the local area. Note that none of these have anything to do with the product itself.

In order to succeed, a product team has to become focused, excited, and almost a little obsessed, with two things:

The outcome they are ultimately trying to achieve
The needs of the users they seek to serve

The product the team chooses to build is simply a way to satisfy those two things, and the more dispassionate the team can be about the specifics of the product, the more likely they are to focus on making the product as a whole achieve its purpose.

‍

‍

Case in point: Vine

‍

The failure to take this approach was a major contributing factor in the demise of Vine, the six-second video app which at its peak had an audience of approximately 200 million users.

Two of the biggest reasons Vine failed were a lack of vision, both in how to sustain themselves and what their purpose was, and not adapting to meet the needs of their users. They stuck with being a six-second video platform – very much a feature – instead of aiming to be the number one platform for short-form video content – an objective.

Vine’s position as the best place for short-form video was taken by Snapchat, who were then beaten by TikTok, who may well be beaten by Instagram. Not only are these platforms outcome-focused, they also strive for continuous innovation – in some cases having to reinvent the product they started with.

‍

"A couple of things plagued Vine, and it all stems from the same thing, which is a lack of unity and leadership on a vision."

Ankur Thakkar, Former Head of Editorial at Vine

‍

The path to becoming outcome focused

‍

So, how do you keep your team from becoming too attached to their product?

One of the most impactful changes that you can make is to move away from traditional roadmaps, with specific features planned far in advance, and instead move to OKRs – objectives and key results. These set out what the product team is tasked to achieve, how that fits into the overall mission for the organisation as a whole, and empowers them to find the best solutions.

Along with OKRs, it’s also important to ensure that product discovery is a continuous process. Product discovery is the collection of activities which happen outside of building a scalable product – listening to users, experimenting with new ideas, testing them, and learning what’s likely to work and what’s not.

‍

"When well-written OKRs are given to teams as their new measure of progress and success those teams have to now figure out what the right combination of code, copy and design is that will result in those changes in behaviour... Success is defined by our key results, not by the deployment of a specific feature. Teams work in cross-functional collaboration to propose ideas, test them, validate/kill them and move forward in the most objective, evidence-driven way they can."

Jeff Gothelf

‍