Know what to build before you spend

Product discovery is the work that decides what to build before anyone builds it. It answers four questions: who will use the product, what they need from it, what the first release must do, and what it will take to build.

It is not a long requirements document. It is time spent with the people who will use the software, a map of how their work runs today, a prototype they can try, and a plan built on what was learned. The result is a first release small enough to build with confidence and specific enough to estimate properly.

Discovery is where most of the expensive mistakes in software are cheapest to fix. A wrong assumption costs an afternoon to change in a prototype and far more once it is built into screens, databases and integrations.

Discovery pays off whenever the cost of building the wrong thing is high. That includes a new product for users you don’t know well, software that replaces how a business has worked for years, an idea that has to convince a board or investors, and any product with payments, regulations or other systems at its centre.

It matters most when the users are far from the people paying for the software. A wholesaler’s retailers, a clinic’s patients, a farmer producer company’s members and a lender’s borrowers all work in ways that are hard to guess from an office.

It is less useful for a small, well-understood change to software you already run. There, a short conversation and a sketch are usually enough, and we will say so.

The most useful findings come from watching, not asking. People describe their work as it should be; watching shows the workarounds, the paper notes and the moments where things go wrong.

So we go where the work happens. In our own projects that has meant time in villages, at collection centres and at the Lasalgaon market with farmers near Nashik, who talk rather than type; mornings at a Hyderabad clinic group’s front desks, where paper tokens hid how long patients really waited; and days in a Rajkot gold jewellery wholesaler’s workshops and in retailers’ shops, where nobody remembered a design code but everyone remembered a picture.

Where travel isn’t practical, we interview by video and ask people to show us their screens. Interviews run in English, Hindi or Gujarati, or with people who speak the user’s language, because people explain their work most clearly in their own words.

After the visits, we write up how the work runs today on one map: every step, who does it, which tool or spreadsheet they use, where information is retyped and where it waits. Nobody in the business usually sees the whole of it until it is drawn.

The map turns opinions into facts everyone can point at. It shows where time is lost, where errors come from and which changes would help most. It also becomes the starting point for design, because each screen in the new product replaces a step on the map.

From the map and the interviews we pull out the few findings that matter most, written as plain statements with the evidence behind them, such as “Retailers order on WhatsApp because it is quick, so the app has to be quicker.”

The first release should be the smallest product that makes a real difference to its users. We agree it in writing, together with what can wait for later releases and what shouldn’t be built at all.

Choosing is the hard part. Every feature sounds useful in a meeting; the research shows which ones users will reach for every day. We weigh each candidate by how much it helps users, how much it matters to the business and how hard it is to build, and keep the first release tight enough to launch and learn from.

We also agree how success will be measured, such as orders placed without a phone call or appointments booked online, so that after launch you can see whether the product is doing its job.

A clickable prototype shows the product before any code exists. The key screens are designed and linked so that a user can tap through the main tasks on a phone or a laptop, as if the product were real.

We put the prototype in front of the people who will use it and watch them try. Where they hesitate, misread or get stuck, the design changes, often the same day. A few rounds of this find most of the confusing screens, and they are far cheaper to fix in a prototype than after launch.

The prototype also helps everyone else. Your team, your board and your investors see the same product, instead of each picturing their own.

Some questions can’t be answered with a prototype. Can the accounting software return a retailer’s credit limit? Will an AI model read handwritten slips well enough? Does the payment provider support the mandate the business needs? What do the rules require before a borrower signs?

We list these risks early and test the ones that could change the plan, with a small technical proof where needed. Regulations and data protection rules are mapped against the journey, so they shape the design from the start instead of being patched in afterwards.

The same goes for the choice of technology. Whether the product should be a mobile app, a web app or both, which systems it must connect to, where its data should live and which parts could use a ready-made service instead of new code are decided here, with the reasons written down.

Discovery ends with a written plan you can decide on: the first release and what follows, the team it needs, the order of work, the risks and how they will be handled, and a cost estimate.

The plan also says what would change it. If a technical proof is still open or a partner’s system is unknown, the estimate shows which part depends on it and by how much the work could move, so nobody is surprised later.

Because the estimate rests on known screens, data, integrations and rules, it is far firmer than a quote on a feature list. It is a document you can take to your board or investors, or use to compare teams, and it stays yours whatever you decide next.

We need a person who can decide, a few people who know the work, and access to real users. The decision-maker agrees the question at the start and the first release at the end. The people who know the work explain how things run today and where it hurts.

Access to users is the part only you can open. Introductions to customers, retailers, patients, partners or field staff, and permission to visit them where they work, make the research real. We arrange the schedule and bring the questions.

Anything you already have helps too: sales data, support tickets, past research, spreadsheets the team relies on and screenshots of the tools in use today. They show where to look first and save interview time for the questions only users can answer.

When discovery ends, the next step is yours to choose. If you build with us, the same team carries everything it learned straight into design and development, so nothing is lost in a hand-over and the first sprint starts on known ground.

Discovery doesn’t stop at launch either. The questions from the first release, such as what users try that the product can’t do yet, become the research for the next one.