Fail small to win big with your digital products

I am sure that everyone who is reading this blog has worked hard and had some failures along the way, for all of us those mistakes became learning experiences. So we were able to take those learnings and make adjustments to our future ideas, meaning we were able to make the best decisions when it counted the most.

Now we have all this experience in doing this with our lives, why do we not do the same with Digital Product development? Why don’t we shift our attitude on features to ones we can fail and learn from, then when we release a big feature it's always a success?

Changing our process on features

Before I go any further with this, I want to clear up what I am talking about when I say feature.

If you are thinking about 10 developers spending 4 months building a full backend, a clean UI, with a full user roll out then let's think on a smaller scale. What about 2 developers spending 2 weeks building only a UI that 10% of the user base can see and use for 3-4 weeks.

So this changes our feature output to a high number of small changes that a portion of users can see.

The next thing we need for this process is to know what our users are doing with our product, and having a dedicated team of analysts to achieve this is so important.

Currently, in Product, we are obsessed with pre-build ideation, user interviews, and gorilla testing to design a user-centric product. However, once it’s live we often don't invest nearly as much into how users actually interact with the product.

We build conversion funnels and then don’t act on it, or share customer journeys with no responses. Making sure we are firstly aware of what our product vision is and then how that is separate from how the product is used is crucial to improving our users' experience, if that is either to pull their usage back to our vision or leaning into users' usage habits. 

So with an understanding of how users currently interact with our product, a vision of what we want to achieve and a steady stream of features to be tested by the users, we are setting ourselves up for success with a product mindset, not just a project mindset.

With knowledge of where we are starting, where we want to be and then the features are how we get there. Now we have a measurement framework to validate each feature release, which means the more releases we can do the more ideas we can test and gain insight from and the more our product can grow and evolve. 

Putting ideas into action

Now the real fun part starts. We can take all the great (and some terrible) ideas that have been gathering dust in the backlog and look at which ones we can take and implement with our new lightweight strategy.

Knowing our current product metrics we can identify the areas that will see a shift based on the design changes to the product. This means once we release the features to a small portion of the user base we can understand what impact that will make if we were to implement this product wide.

We have all found the perfect product that will solve all our problems only to find that their user journey is a struggle and that you never get to the value. Now the product team might have made an assumption during design and now that is manifesting with our users having difficulties.

This is frustrating for both us as a user and members of the product team because, in reality, it’s neither party’s fault. But with a measurement framework in place, this is the sort of issue we can identify and then resolve through lots of small iterative tests.

Focus on the highest value features 

What we want to accomplish are features that are allowed to succeed or fail based on our users’ usage and both outcomes are a success because we know if they add value and how features add that value.

We believe all companies are really digital product companies, they probably just don't know it yet. Not every feature will make a positive impact, a large portion of them will make no impact and some will even cause a negative impact!

But with evidence and data, we can decide what features we want to build out fully with the larger development team. Deciding on the metrics we want to measure before release means we are planning and thinking about the goal of each feature. This lets us know we are investing our time and money into the features that are going to give us the greatest impact for improvement.

Something we have managed with our full stack teams at Red Badger is the ability to quickly turn around features.

We can reduce the time to success with our feature teams that understand this process or we can help guide and advise your teams on the best practices to add this value with your own product teams. Great products aren’t released like that on day one.

Like everything else, they take time, lots of small changes and one or two really big ones. It’s all about making sure your small ones are allowed to fail so your big ones are always successes.