Milestoned: How to avoid the startup death march

A 'death march' project is bad enough within large organisations; in a startup, it can kill the whole company from the inside out.
Two people walking on the mountain side

You’ve got an idea or a project on your hands. It’s a big one though… and you’ve seen how easy it is to be burned by a project like this. You don’t want to lead your team into a death march though. Everyone involved in a death march knows it can’t end well - even as they continue to work on it. This is bad enough within large organisations; in a startup, it can kill the whole company from the inside out.

So you have to approach your big project with the care and consideration it merits... but you also want to stay agile. Spending months planning years ahead is a good way to give your competitors the time they needed to beat you to market. You need a way to assess your progress and respond to new developments as they arise.

These are the challenges we faced when we first looked down the barrel of the Wrisk MVP. How do you get from a great idea and some talented team members to a fully functioning app within a tightly regulated industry? What do you even mean by ‘fully functioning’? What does your MVP actually look like?

At Wrisk, we demystified our delivery by creating simple milestones.

Cameras parts
Looks complicated... until you try to build an app from scratch. | image: Vadim Sherbakovinsurtech

What’s in a milestone?

So, to be clear: a milestone should still have the end goal of contributing towards an MVP (minimum viable product). A former colleague of mine, Mike Dixon, makes a great distinction between what an MVP is and isn’t. If you can build your MVP in 3–6 months, you probably don’t need milestones.

Milestoning works best where your fundamental hypothesis is one based on multiple points in a value chain - that is, you need to build a pretty complicated product requiring multiple processes (entering customer information, taking payment, offering refunds, etc.) just to get to a point where you can test your most basic hypothesis.

Most tech companies working in regulated industries like financial services will fall under that category. Developing an insurtech app, we knew from early on that we would need to break our complicated MVP up into milestones.

So what’s a milestone, anyway?

Well, a milestone should represent a meaningful slice of functionality that I can use to gain feedback (but won’t enable me to prove my original product hypothesis). For example, let’s say my MVP looks something like this:

Revolution in retail, I know. The first meaningful thing I could gain feedback on would be the Browse portion, as marked by the dashed line. So I’d work with the team to agree on a backlog (to do list) of stories (bitesize tasks) which would lead us to the milestone.

Cutting a milestone in this way achieves three things:

  1. It’s short enough that we can maintain a lean backlog of stories. (I don’t have a big analysis backlog weighing me down)
  2. It’s substantial enough that I can get some users in to test that particular milestone as a whole once it’s finished
  3. I can show meaningful progress towards the vision I’ve set out for stakeholders or investors

Particularly in a startup setup, the last point is key. Without users, revenue, or any sort of real metric to evaluate success or potential of the product, investors can use milestones as a way of measuring progress towards our joint goal of releasing a product to real customers.

Once I finish splitting the planned MVP into milestones, I might have something like this:

By splitting at this level in this way, I maintain my ability to be agile within each feature. I can test and learn as I go, and continue to show value to my stakeholders.

Using this approach, we ended up with six milestones at Wrisk, spanning just over a year and a half. These enable us to report on our progress against clearly defined short-term requirements rather than our more complex and distant MVP. We present and record a showcase for investors and other stakeholders every two weeks. Having milestones has made that process easier for us, more useful for them.

If we had tried to estimate exactly how long those six milestones would take, that would have been a big drain on time and resources. We’d have guessed things wrong, we’d have committed to dates that weren’t feasible and we could have come out the other end of those years with a product nobody wanted to use.

The milestones approach saved us from that. The biggest advantage for us is that each milestone also allows us to take stock of how well we delivered it and whether we’re well placed to deliver the next. We’ve allowed ourselves ample room to pivot where we’ve struggled with complexity or received feedback. This gives us a much stronger chance at succeeding in the fickle court of the free market.

Here’s what to avoid:

Feature specificity

Be careful to frame your milestones in terms of value to customer, not features. While a feature might sound great back when you started, it needs to contribute to that overall hypothesis you are trying to test. Otherwise, your journey through the desert might meander through some stories that, while they might unlock some investment or make a stakeholder happy, are offset by the time and cost you spent to get it there.

Untestable milestones

A milestone needs to be testable in its own right. Whether this is through controlled user testing or public alpha/beta testing, gaining some early feedback of what is working and what isn’t can really save you time - and money - later on. At Wrisk we struck feedback gold when an early milestone proved a particular design pattern wasn’t working as well as expected. We pivoted and have a much better version of the product to test with the public.

Ignoring non-technical work

Regulatory work, due diligence, sign-offs, etc. etc. These pieces of non-technical work are major undertakings in themselves. All industries have some form of regulation which requires significant time investment and resourcing to progress. All these pieces require constant feedback from regulators and third parties; incorporating them into your milestone plan will ensure you’re ready for those dependencies.

Oversimplifying just to complete a chain of processes

For our most recent milestone, we did a great job at cutting across the entire value chain, getting some really complex functionality working. However, this functionality was operating on some very simple assumptions in other parts of the product. We also wasted some time building components that wouldn’t exist in the final app because we were trying to go end to end.

As I said above, looking to go end to end isn’t really the objective with milestones. It’s to gain early feedback on specific processes from stakeholders and users. An end to end that oversimplifies these processes undermines that and is more likely to cost you time.

Not celebrating!

Geran Butcher playing crazy golf
Definitely not putting the ball the sand. Definitely. | image: Amelia Cookinto

Milestones aren’t just useful to demonstrate your progress to investors: they also give you a way to take stock internally of how far you’ve come. Last week, team Wrisk celebrated hitting our most recent milestone with a fancy lunch followed by crazy golf in the middle of the City. (We’d never seen so many people playing crazy golf in suits!)

When you’re in an early stage startup building a complex product that isn’t quite ready to show off, you can lose track of how much progress you’re making. In the worst case scenario, people may feel like they’re on a death march even when development is going perfectly to plan. Milestones give everyone in the team a chance to understand and appreciate how much they have accomplished and how they have individually contributed to a much bigger goal.

Like the sound of how we work? We're hiring!