Our approach to product discovery

Last week we introduced HATCH to a new customer. As always, we used our standard deck to explain our way of working. All-in-all it was a good session, and we left the meeting feeling our story ‘clicked.’

Over the past years, we’ve become better at these early meetings but suffices to say they are not always successful, so when this client contacted me to confirm, I jumped at the chance to collect feedback.

“We especially like the way you propose to kick-start the project. Running a small discovery stretch before making a big investment makes a lot of sense. You should put a bigger emphasis on this in your marketing material.”

As you can imagine, this was a clear call-to-action on my end. When founding HATCH, our entire story was based on the project discovery phase. Somewhere along the way this message got pushed to the background.

Why Prototype?

I have always felt there is something fundamentally off about the way our industry organises project discovery and analysis. The introduction of agile has made the situation slightly less dire but still, most of our clients fall into one of two categories:

The first group, typically large organisations, will start any project by mobilising a small army of analysts. The problem is that these analysts are typically trained to focus on reducing the project’s risk profile: technical feasibility, system integration and data model. I am not saying these are not important, I am just saying this is not where I would start the journey. More often than not, this approach results in a detailed requirements document, creating a false sense of security and stifling innovation.

The second group are those that believe their ‘shiny new agile process’ renders any analysis and due diligence obsolete. “Let’s just start building something and we’ll figure out the exact destination along the way.” While I must admit I do have more affinity with this way of working, it comes with clear pitfalls and risks. At the very least this makes the project difficult to plan, and it always comes with expensive learning cycles.

As with many things, context is key, but in general we believe the ideal approach sits somewhere in-between. Don’t start your project with detailed analysis but also do not go in blind. Create ‘cheap’ learning cycles and test your assumptions early and often.

Enter the prototype

As I already mentioned, the ‘Let’s just start building’ mentality does really resonate with me. This is why, even when I was an engineer myself, more often than not, I would start my assignments by building the graphic interface first. Whenever I could, I would first demo the interface before continuing work.

At HATCH, we have adopted a similar approach. Our projects usually consist of two phases: the discovery phase and the implementation phase. Each comes with its own budget and deliverables.

The discovery phase is a pre-approved time-box, typically two or three weeks, within which we create a high-fidelity prototype. This can take the form of an interactive wireframe or, more often than not, an actual working app. The goal is to design the most important user interactions, while the communication with the server and all the data is completely fake.

During discovery, we host daily demo/feedback meetings with a small, empowered client team. This team plays a critical role in the prototype’s success, making sure we focus on the most important things first and taking decisions when needed.

Depending on the footprint and budget we favour the interactive apps because they allow us to go much deeper in the interaction design. It also means we can already tackle some of the trickier technical challenges.

When done correctly, the prototype

• allows us to evaluate new concepts without going through the entire implementation cycle.
• allows us to identify technical risks and greatly improve our ability to create a solid roadmap (read: better estimates)
• allows our client to grow confident in our abilities and the end result’s success.
• allows our client to approach internal stakeholders to assess the project’s value before any major investments are done.

We have found that our prototypes always spark much more meaningful conversations, conversation I’ve never had based on a lengthy requirements document.

Why do we not see this more often?

While we certainly are not the only agency to take this approach, it is still not a common place for a few reasons.

For this to work, discovery and implementation truly have to be separate projects with their own contract and deliverables. Both parties should feel comfortable disconnecting after discovery without feeling the project failed. While this seems logical, it is really hard for people to come to terms with.

As a service provider, it also poses a few extra challenges; you need to be convinced your solution will hold up against your clients scrutiny, or you’ll only execute very short prototyping-projects.

Above all else, you need a team with the right mindset. As you can imagine, our prototyping projects are high-adrenaline, having to demo progress on a daily basis is intense, kind of stressful but very rewarding. It always requires some detox to flip between discovery and implementation. Most software engineers tend to think of themselves as ‘craftsmen, perfectionists.’ I still count myself among this group and would still argue ‘passion for the craft’ is a requirement for any Hatch-ling but it has no place during prototyping. All that matters is making sure you bring the best user experience first, anything else comes after.

With HATCH soon blowing out six candles, I am proud of the way we have come to shape our discoveries. Hoping we can add many more candles to our cake.