Product Discovery Workshops and troubles they help you avoid

Every digital product we create is built with the Build-Measure-Learn cycle in mind. We add to our procedures any good practices that are missing and remove those that (for some reason) aren’t working. In this article, we will tell you more about the way we prepare for building a product and what could happen if we tried to start development work without a product discovery workshop?

New digital products and our process

Every digital product is different. And whenever we want to start developing a new product, we need to look at that product’s needs, its business context and the industry, as well as the client’s needs. That is why it is impossible to have a one size fits all solution for a successful product start. We do, however, have our procedures. Tested, adjusted, and improved after developing every one of our three hundred products.

About product discovery workshops

Whenever one of our clients wants to develop a new product, as a part of our usual process, we organize a product discovery workshop, where:

The development team meets the product’s vision, and the business idea that stands behind it. It’s time to meet and learn from each other, discover each other’s needs and expectations.

As a result, our development team has a better understanding of the client’s idea, and the client has a chance to listen to their feedback. We also assign a dedicated product strategist (PS) and a new products guide (NPG) - a role responsible for a smooth start to development.

One of our clients - a large corporation that we’ve been working with for many years - decided to handle the start of the product without taking part in our workshop.

Using their own resources they wanted to prepare the product for development, as well as introduce the development team to the requirements of the product (aka conduct the onboarding process for developers). How did that go?

You might be also interested in the article:

Why build digital products based on user research?

What were the results?

Despite the client’s commitment to the process, not everything went as they hoped and as a result the product was not ready for development. This became apparent only when we attempted to start developing it and noticed:

• the lack of a new product guide (NPG) or a similar role, assigned to the process,
• our development teams had a difficult time joining in on the work,
• we weren’t aligned in terms of the clients’ needs: the client needed the core of the product, while we were under the impression that they wanted two microservices,
• the roles weren’t mapped out; this made it more difficult to remember the specific skills of each team member, as well as which problems each team member could solve,
• the team had no success criteria, which meant that they didn’t know what the client was expecting from them.

With so many issues in need of solving, the development team was struggling to get anything done. The team soon fell apart and the client decided to continue developing the product on its own. Looking back, once the development started it was too late to save the situation because it’s impossible to develop a product without understanding what the team needs to achieve.

You might be also interested in the article:

How to choose a product development partner in a VUCA era

What did we learn from this failure?

Our development team and client relationship roles learned that they need to better communicate the risks that they see from clients’ ideas, propose their own ideas more often, and take ownership for the onboarding process of the development team. But the biggest lessons came for our NPG roles, who updated their procedures with good practices like:

• Remember that the purpose of the NPG role is to take responsibility for a successful start for the product. Even if it’s the client who conducts the workshops.
• Join the Slack/Teams channel that the client uses to communicate with their teams. This way, an NPG will know about potential problems in the product as they arise.
• Make sure that the metrics and domain knowledge about the client’s business, as well as the client’s expectations, are all collected and taken care of.
• Prepare an onboarding plan for the development team and help the client to keep track of it.
• Monitor the completion of the development plan: for example, in weekly meetings with clients.
• Speaking of meetings, an NPG should meet more often with the product owner and a Scrum master (if they come from the client’s side). This is to make sure that everyone knows the plans and their role in the development of the product and onboarding of the development team.

In the future, we will do better at convincing our clients to let us conduct the product discovery workshop. After all, they work - as an example, one of our long-standing product owners Cathy Cao liked them so much that whenever there’s a need to discuss a new project with her team, she tends to say:

Can we do a Boldare-type workshop?

While the lessons we learned are valuable we would prefer not to experience this situation at all - and save the client and our team from the frustration. The best that we can do now is to remember this story and make sure that in this case, history does not repeat itself.