Product me the money!

Board with notes

Ever wondered why there are so many products that look good, work but don’t work well for you? Why the last update to your favorite app was so ugly and unintuitive you almost ditched it? Or why you remember that big launch but never come across someone using the product? While these can be explained away by a brutal market, poor product development plays a large part. Product discovery is a process to reduce the chances of this happening to you, and gives your product a better shot at success.

We’ll aim to answer these questions about product discovery:

  1. What is product discovery?
  2. How is it done?
  3. Why do it?

1. What is Product discovery?

Product discovery is a process and set of activities that help make sure that the products we are creating are useful. Through the process, we are able to validate our problem and proposed solutions and gauge the potential market. Product discovery allows a business to understand its customers, the problem being solved and determine if and why to build a product This process is applicable not only for new products but also for feature improvements, launching in new markets, marketing and any other action that has significant impact on the business.

Product discovery is the second stage in the product development process at Zegetech that includes; Scoping, Discovery, Design, Development and Pilot. The importance of the discovery phase was realized after a lot of projects with some successes and many failures. It allows us to ‘see’ into the future and gauge if a project might work. While it doesn’t guarantee that what we build will be a success, it protects us from building terrible products.

xkcd: New Products

2. How to do a Product Discovery


The product discovery process will differ from organisation to organisation. However, it involves these general steps:

  • Understand, prioritize and clearly define the problems
  • Come up with possible solutions to the identified problems
  • Pick the best solutions and build prototypes for them
  • Test how well the prototypes work with existing or potential customers
  • Use the data gathered through testing to redefine the problem or refine solutions

One format for carrying out product discovery is the design sprint. This is the format we use at Zegetech. The concept note generated during the scoping phase forms the main input to the design sprint.

Design Sprint

The Design Sprint is a timeboxed format for product discovery developed and popularised by GV (Google Ventures).

The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.

The design sprint borrows concepts from different disciplines including behaviour science and design thinking. It compresses product discovery into a single week allowing a team to learn without building and launching an actual product or MVP. The design sprint is carried out by a small cross-functional team consisting of members who will actually be building the product.

Within one week the team explores the problem and chooses a single high-impact theme to explore. They then propose individual solutions and collectively narrow down to just a few for which they build prototypes for. The team then tests the prototypes in one-on-one customer interviews noting down the effectiveness of each. The process can be repeated as often as required till the problem is clearly defined or discarded as not viable. You can learn more about the process by watching the story (second video).

Daily breakdown of the design sprint:

  • Monday - come up with the problem map. Understand the problems you want to solve and choose one to focus on during the week.
  • Tuesday - each team member comes up with solutions to the problem individually.
  • Wednesday - each member goes through the proposed solutions individually, and then the team collectively narrows down to the best solutions.
  • Thursday - divide up tasks and build realistic prototypes for the chosen solutions.
  • Friday - test the prototypes in one-on-one interviews with customers

A Software Requirements Specification (SRS) marks the end of the product discovery phase at Zegetech. The SRS is prepared in the week following the discovery sprint, guided by the prototypes and insights of the sprint.

3. Why do Product Discovery?

At the end of the product discovery process the team will have a deeper understanding of the problem to solve. The assumptions made about the product will have been tested and proved or disproved. The team will intimately know who their customers are, why they will want to use the product, how the product will be differentiated and what the business can expect to gain from working on the product. In addition to the benefits derived from any product discovery process, the design sprint:

  • Saves time - conversations that could have taken months are completed within a week.
  • Helps build trust - working in a cross-functional team allows each member to discover what each one is good at and builds rapport.
  • Allows the team take big risks - the reduced resource investment means ‘crazy’ ideas can be tested with minimal impact to the business.

All these combine to ensure that the business is building a product that has utility, is needed by the market and aligns with the business’s goals. In turn ensuring that the right resources are allocated and giving the product a good chance for success.

Want to have a quick chat?

We are only a phone call away   +254-705-504211