How we work

Discovery is both a discrete phase in software development and continuous activity throughout a project's lifetime. But what exactly is discovery and why is it so important?

What is Discovery?

Every software project starts with uncertainty. Precisely how much will depend on any number of contextual factors such as domain complexity, project size, technological constraints, market-forces, personnel, and so on. It will also depend on how far you’ve taken your product idea - is it still just an idea, requiring proper analysis, validation and market research, or do you have you have a clear vision of what is to be built and the market it is serving. These are very different starting points.

Our job as engineers, designers and product specialists is to mitigate as much uncertainty as possible before undertaking the work. After all, the greater the uncertainty, the more difficult it will be to determine the effort required to build the software. Therefore, before we can give any sense of the cost of developing a product, we must map out and understand as much of the scope, complexity and uncertainty as we possibly can. We do that in a distinct lifecycle phase known as Discovery.

When do you do Discovery?

If you require any kind of cost estimate for a project, then your delivery partner will insist on doing a formal discovery. It’s almost impossible to size a project without it.

Discovery preceeds actual development, but nearly all the activities undertaken during discovery are things that will be done on the project regardless - by front-loading them into a formal discovery phase, the development team has the opportunity to really understand the size, scope and complexity of the challenge.

Just how much discovery is required will depend on how many knowns and unknowns you are dealing with. Clearly, the more time you spend in discovery, the more accurate your estimates will be. The main purpose of discovery therefore is to narrow the ‘cone of uncertainty’ and hence reduce the variance in pricing.

Cone of Uncertainty

But, of course, time is finite and so there is a fundamental trade-off between doing just enough to create an estimate (always an inexact science) versus doing too little and potentially leaving a bunch of unknowns on the table - unknowns which will come back to bite you later.

Is Discovery Always Required?

Not all projects require a formal discovery phase. If you are still at the drawing board, playing with a nebulous idea, then you will first have to go through some form of Product Definition to properly validate and define the ask. There is simply no point sizing a piece of work if you have no understanding of what is to be built or even if there is a market for your product.

We will often be engaged on a pure time and materials (T&M) basis in which case we may avoid the discrete discovery phase altogether and instead incorporate the discovery activities into the main project timeline. In many ways, discovery is never done. It is continuous task - as new requirements or opportunities arise within your business, the need to manage complexity and uncertainty never goes away. Managing risk and the unknown is a near constant in software development.

What are the outputs of Discovery?

The actual outputs of a discovery phase will vary project to project. The following are just some of the things a team may choose to do to move the dial forward and build a picture of what needs to be built.

  • Build prototypes to mitigate unknowns and complex challenges
  • Create an initial roadmap and backlog of user stories
  • Define delivery themes condensed into high-level epics
  • Identify key personas and system stakeholders
  • Identify paths that achieve highest positive impact
  • Develop UI wireframes or clickable demos
  • Define the solution architecture including technology stack
  • Verify 3rd party integrations
  • Create initial delivery plan, milestone definitions, resourcing, etc
  • Define a project charter and communication plan
  • Estimate the effort to build the software

Many of the tasks and outputs will focus on technological uncertainty e.g. 3rd party integrations or technology choices. For example, we recently completed work on a cross-platform 3-dimensional modeling application, and a good chunk of the discovery was spent comparing an established technology platform with a radical new approach. The new approach promised greater productivity, however developers are often drawn to shiny new things like moths to a flame, and to their peril - the lack of maturity in new technologies will often lead to a whole new world of pain. So, we had to prove that the new approach was not just viable, but that it was indeed more productive and easier to use. (Which it was, and proved to be the right choice.)