James King

Product people often talk about doing continuous customer discovery, which is great. Engineering teams also talk about wanting to do some discovery before building something complex, which is great.

But next time someone says they need to “do some discovery”, ask them what they mean by the word discovery.

I worry that people are using the same word to mean different things and, without validating what they mean, there is a risk that they are not saying what you think they are saying.

So when I recently told people that “it would be good to have milestones in your discovery work” I was probably not being as helpful as I would like to think I was.

Let me illustrate

Where Wisdom should precede planning

UX people do continuous customer discovery. But this is not goal driven or restricted to solving a specific customer problem. This is actually about being curious and open to learning from whatever you observe. This way we learn more about the world of our customers and we can make innovative decisions based on a deep understanding of what their lives are like.

While this work is extremely valuable, we might not produce a plan with milestones when doing it.

We might be able to say that we will spend x days with customers and then summarise our insights by the 15th of March, but we cannot really be more specific. In fact sometimes we might just say that we will spend some time with customers every month and never set a clear goal beyond being wiser when we make decisions about new ideas that we hope will excite a customer.

Overall it is better to be patient and acquire wisdom before we plan a lot of action, rather than plan in ignorance and then commit to what we hope will be a worthwhile endeavour.

Discovery as another word for procrastination

I was horrified once when someone described me as very analytical but suggested that sometimes I use analysis as a way to procrastinate rather than as a way to move forward.

My horror doubled when I analysed what they meant. I wanted to better understand things before committing a team to do work, but the things I was analysing were not actually going to impact the decision to do the work. 

In some cases we know what we are going to do and then someone suggests that we start with some discovery this month and then come back next month to discuss doing the work again.

It is OK to defer a decision for a month, perhaps to get people used to an idea or to see how other things unfold before committing ourselves. But that is not about discovering something, as much as it is about not needing to decide yet.

In this case, strangely, I think we need a milestone but we probably don’t need any discovery. Instead we could just say “we will make a decision on day/month and it would be good to know if “A and B” have happened before then.

If we are doing some discovery this month then we should be able to use that discovery to answer some specific questions, or to remove ambiguity in order to clarify options or something like that.

Discovery to reduce risk and ambiguity

Now we get to where we might do discovery, that may still sound vague, but can have some pretty clear milestones if we want it to.

Back in the day when I was a project manager, I would always start any project or initiative by trying to define what it was. In some agile approaches this was called a concept phase. It need not be long by it would include enough discovery to kill or progress an idea:

• Is this something we should tackle – what problem is it solving for whom?
• Based on what we know now, whose help do we need to understand the problem and create a solution?

These questions be answered very quickly, with a risk of being wrong, or they can become Koans to meditate on over a lifetime. I think the best approach is to time box the investigation and then set a date for completion. In other words create a milestone.

Once we think something is worth solving, we might do more discovery to answer some more questions and you could call this the initiation stage of an epic, and adventure or an initiative:

• How well do we understand this problem? What else do we need to know at this stage to risk allocating more people and time to it?
• What is our plan to tackle it? Do we have access to the right people? How might those people collaborate to solve the problem? What constraints or risks will impact our cunning plans?

Again – we can do a quick and dirty estimation what what we will do, or we can plan in exquisite detail. I think we should generally timebox our work and commit a finite amount of effort before deciding to continue, kill the idea or pause to learn more about something specific. 

That means we might have a could of milestones:

• Concept or problem definition – 1 sprint
• Initiate, scope and prioritise – the following sprint

We might now defer any work while we break for Christmas, send people on a mission to Mars or meet another commitment. Then we might still do some discovery, with even more milestones.

Knowing which questions we are asking

Along these lines, sometimes “discovery”, “research” and “story elaboration” can seem overwhelming and confusing. For example where we might ask a product owner to break stories down before we define the value of what we are doing, or we work on “phase one” of something while our stakeholders think we are working on “everything to deliver a perfect product”.

By breaking our work into specific questions, steps or “milestones” we can create better clarity around what we are asking to learn now and what we are not yet worried about.

Creating milestones such as “problem validation” and “solution design” or “understand customer request” we can bring some structure to our otherwise overwhelming work.

Thus milestones become a tool to help manage discovery rather than a way to report on discovery. I actually use them in private even when others are not expecting any reporting from me.

Cost free product owners to avoid wasting engineering time

The next meaning of discovery is to “meet our definition of ready before getting the team involved”. 

For an evil team of engineers what this really means is that they want the product owner or some other person to do a lot of work to ensure that the team of builders begins with a very clear plan, a great understanding of what is needed, and only a tiny risk of having to stop to resolve any unexpected issues.

For a less evil team, this can still be a source of waste, because the team are story pointing work based on what developers do, measuring developer velocity and productivity and driving the developers to commit to very precise estimates. 

Well – a less evil team, but perhaps not a much less evil team. Some teams make the mistake of believing that work begins when the team starts building something, not when the team starts thinking creatively about it or researching it.

The PO does extensive work and the developers do comprehensive spikes and the team then feel that they will progress rapidly “once they are ready”. However this is doing both the PO and the developer a disservice because knowledge work does not begin when you start laying bricks, but when you start solving the problem.

So a team should really have milestones and definitions of done for “breaking the work down for manufacturing”. Even a broad guess about the time it will take to understand the problem is helpful in freeing people up from the illusion that they are not starting work until they have everything prepared for the final assembly of the solution. So again – we have milestones.

Real Product Owner and developer discovery

If we throw aside the illusion that work starts when we assemble the code, then we are left with a challenge.

It can be hard to precisely estimate how much effort it will take to understand something if we do not yet know where the challenges will be. But we can take an educated guess and set a target time based on that guess. Then we can see where we are wrong and develop better heuristics (guides) to help us improve future guesses.

We can also assess whether we have the people available if we think there will be a lot of work involved in story mapping, story refinement or business rule investigation.

So here we can set a milestone for when we hope to have something ready for the team to start breaking things down for the next sprint, or when we will have a view on a risk or a technical constraint. Doing this is about as hard as setting development milestones for an engineering team when they are looking to estimate when they will have a feature ready to deploy.

But are milestones inherently evil and anti-agile?

One problem with my theory that milestones help in discovery is that when some people say milestone they actually mean contractual obligations on which payments and personal reputations are based.

If you are setting milestones in a contract (even an informal one) then I guess you should consider contingency, confidence levels and other things.

But for me, a milestone is not a commitment, it is a guestimate about when something will be done, or when it should be done if we want to be on track to launch our shiny new feature before the Christmas sales start. 

Both hitting and missing milestones helps people to adapt their plans based on what is actually happening and setting milestones helps people plan and prioritise their work around everything else they need to do.

So I guess milestones are as useful in discovery as they are in delivery and they are as dangerous too.

I think we should have milestones in discovery so that we can recognise when we learn enough to either change direction or progress toward a destination we want to reach.