I just finished a 4 week product discovery phase with a client who had a little more unusual challenges than other clients I have worked with in the last few months. They have a complicated business domain, a lot of security considerations but mostly they have a vision of where they want to be in a few months. A pretty grand vision that explores and relies on their current domain a lot. So to truly help them our team had to really understand some of the intricacies of their business.

To be successful with this kind of challenge I often rely on a Domain Driven Design approach. Every meeting you facilitate, you are building trust, learning and getting more intimately involved with your customer’s success. The longer your engagement, the deeper your understanding and knowledge becomes and your relationship with the customer becomes a very comfortable and easy one. 

You are not the domain expert

As a facilitator responsible for gathering information critical to successful product delivery, it can be tempting to leverage your expertise to guide a conversation to a particular outcome. To yourself it might feel like you are familiar with a certain industry, you think you already understand a specific technology stack or know how a team operates. While this might seem like an advantage that shortens the product discovery cycle in the short term, it can result in a highly biased readout with a whole lot of incorrect assumptions.

Good discovery, therefore, means stepping away from the expectations of “expertise” and instead playing the role of a total novice. 

Ask questions as though you are starting with a baseline of no knowledge: What is this called? What does this do? Tell me how this works? Why is it important?

Making sense of information deluge

As a facilitator, it is important to ask abstract and open-ended questions to get all the information possible. But due to the nature of the questions, the answers will invariably wander off-topic. Domain-driven design allows for—and even encourages!—tangents. Taking copious notes, being able to classify ideas according to a bigger picture, and making collaborative decisions will help make sense of what you are hearing.

You are listening for and trying to identify opportunities and gaps in both the technical and business areas; processes/methodologies, workarounds, pain points. 

• Write down everything. 
• Use a whiteboard tool to collaborate and visualize what you are hearing. 
• Have an event-storming session to hear everyone’s opinions.

It is also not uncommon for the room to go quiet. Is it something that got mentioned that is potentially a no-go zone? Or even - is there someone present that is not saying anything? 

As facilitator you have to be tuned in to pick up on this. Maybe they are wrapped up in a really complex problem, or are afraid to speak up. Maybe they need a peer that they are willing to open up to.

Be a total partner

Imagine you want to install a new kitchen - so you hire a carpenter. He assures you he has all the tools, the skills, he can source all the latest cabinets, faucets hardware etc. But as you have your first conversations he is not paying attention to how you want the kitchen to function. 

So he builds you a big, beautiful looking kitchen with all the latest cabinets and fittings, but the layout is not what you wanted. Maybe the fridge is just those 2 steps too far and every time you get an ingredient you are reminded how it’s just not set up the way you wanted it. Or there is no counter space for your favorite coffee machine. And why does this huge cabinet create this dark area in the corner? 

If only the carpenter was more interested in your intent with the kitchen rather than using the latest quick-assembled cabinets that had him complete his work with ease.

Product discovery is an ongoing process. In many ways, you are a mirror to the client. Check in by presenting everything back to the team to promote a shared understanding. It might sound silly, but hearing something out loud can sometimes highlight previously unrecognized ideas or pitfalls.

Domain driven design calls this the “ubiquitous language” that is created around the clients needs and the things they deal with. But you won’t know how to speak the language without asking questions in discovery and eventually on a daily basis. Ideally you reach a place where documentation is basically unnecessary because the code will be modeled/structured on the business requirements.

Bringing engineers out of the engineering mindset and making them a partner to your customer is key. There are a lot of people out there that can write code or use a new framework. Engineers that are willing to understand their customers’ business and what they are trying to achieve are scarce and special. Domain-driven design tells you that these people are at the heart of what makes your software a success.

Knowing when to hand-off

Discovery is meant to find things, it does not imply that you have to be an expert at everything. Should you uncover something where a specific expert is required - call it out! Perhaps a UX expert will need to join discussions about a complex user interaction. 

In a FinTech organization, a security or compliance expert might be critical. If your own company does not have this expertise, speak to your customer and get a specialist organization to deliver in that field.

Ultimately, discovery tries to answer the question, How do we get from here to there? To truly understand what it will take and to come up with a plan you need to take in all the information, follow the requirements and have your engagement centered around great individuals. If it extends to an expertise beyond your own, hand off to a trusted partner that specializes in the particular field.

Resources: Event Storming, Domain Driven Design by Eric Evans, Conway’s Law, Agile Manifesto