Product Design, Roadmap and Estimations

I’ve written about this topic already, a long time ago. Yet, it was with other words, with less experience. And I’m doing it again, as throughout the teams I met and worked with, it still seems like a key pushback, while it really is in the best interest of everyone, engineers, PMs, and anyone else alike.

Don’t make it hard on yourself

Before you read any further, let’s make one thing clear. Nobody is asking you to tell precisely on what date and time you’ll deliver a given feature. Yet, it’s key that over time, and within a given team, some predictability appears, and that you avoid either procrastinating or releasing too early.

You’ve read that correctly; estimates are not about answering “how soon can we tell our customers we’ve solved this/that problem?” as much as “how much effort are we willing to put into this before we’re happy with the result, and can move on to the next item?”.

It’s a matter of finding the right balance while dealing with all sorts of impediments, changing teams and changing business challenges, and being human.

Fact: on that last part, in France, forget about a major release in May; it’s a fallacy to believe this will ever happen. And whether we’re talking about a month when there are many of those bank holidays, or simply because your teams are made of humans who deserve to be treated as such, to disconnect, care for themselves and their loved ones, there can be so many reasons why you’d better respond to change over following a plan.

Now even though I’m against dogmas, the following should be considered in its entirety. Just doing a small bit of it and then saying “it doesn’t work” can’t be acceptable. It’s a paradigm.

First: do you need estimates?

A new occasion for me to cite Donald Knuth (in part): “[…] premature optimization is the root of all evil […]”. I’d assert that if you’re in an early stage company, still discovering what you actually want to build and why, and still building your team, you might pass.

There are some very decent and proven methodologies that don’t really require any sort of estimation, such as Extreme Programming. This is particularly suitable when working with less than 5 devs, and even more if those devs have acquired some seniority in product-led businesses.

As I quickly mentioned, the need for estimates arises from the need of predictability, and of course: communication. It is about telling people around when they can hope to get a solution to their problem. Fair, isn’t it?

Think of any of your tools. Whether it’s broken, or non-functional, and that you are not the person who can fix it. Set aside the frustration; you simply have a list of things to do, and need to prioritize. What will you do next, until your tool is functional again? Because the task you need to achieve with it is still your top priority, and yet you won’t just procastinate. Will you have time to do A, B and C? Or just C?

Well, that is precisely what’s in your customer’s mind. And in your support team’s mind. And sales people’s mind (well, it shouldn’t be in those minds actually: we should always sell without any promise of what will happen in the future, right?).

Understand what an estimate is

When I first got to work with Scrum, I worked as a PM with the engineering team to transform the complete existing organization. The company existed since multiple years, and was “sort of” comfortable with a Waterfall methodology. Except it was facing emerging practices and tooling (yay, Git!). We quickly started to work on “estimates”, pretty much like described in the article I cited above.

More specifically, we were talking in “complexity points”. There are many options there, but I find this one as the most efficient. And I have a strong opinion about some other options.

One key point we had to evangelize about internally: there’s no exchange rate value between points and man hours. Back to my intro: it is a fact that no dev will ever be able to tell how many minutes or hours it will take them to develop a given thing. No matter what another “senior” dev, or the CEO, will ever believe. Take into account impediments. Add technical debt. Plus the changing briefing. And that crash in production (well, it’s yet another of those impediments).

The first and most important thing to keep in mind, is that an estimate, no matter what metric you’ll use, should never be an absolute value.

To a broader scale: an estimate should never just be about “how long will it take me to write the lines of code”. Especially in a world where the AI might do part of it for you. It should include the whole technical design and delivery process. From the “OK, what is it that I want to build now?” to the “Hey folks, usage metrics come in!”.

Start giving numbers, don’t worry

The only thing that we can tell is: is this thing a priori (keep that in mind) more complex/complicated to build than the previous thing we built? Have we built something comparable in the past?

Then, you’ll indeed want to grade/put a number, simply because it marks a reference point. The first time you do it, that metric will actually be the best and the worst estimate you can give. But it doesn’t matter, as: 1. you’ll probably never be 100% accurate 2. it’s an iterative process, you’ll do better next time.

Another key consideration: divide to reign. You can probably get a decent estimate for updating the color of a button on a given page of your app. Now building a new search engine into your product is certainly a much bigger endeavour.

Break it into smaller parts. Each task/story/development should lead you to an independent, testable deliverable. Ideally, something you could push to production and let some users benefit from, or feedback on.

This is where using the Fibonacci sequence (1, 2, 3, 5, 8, 13,…) in estimates becomes handy, especially when estimating the complexity in delivering a feature. Anything below 5 should be “simple”, predictable, like changing a button’s color. Now as soon as you start thinking in features, you’ll probably want to grade it between 8 and 21. Note that the Fibonnacci sequence increases in values very fast: this reflects very nicely the uncertainty that appears when the complexity of what you want to build increases.

Now an even more important consideration: the values will always depend on your team, on the software you’re building, on the technology stack, and so many more parameters. If you work with two teams that own two different parts of a same company’s product portfolio, they might very well give different values to somewhat similar developments. It’s OK! It’s part of the deal. Again: absolute values don’t matter.

Iterate

So you’ve planned and completed your first sprint/development cycle. Guess what? You miserably failed at estimating. You might not even have delivered some of the features at all, and barely starting thinking about it.

IT’S OK!!!

Just like you took a first shot at quantifying a feature delivery, then figuring out if the others were more complex, less complex or equivalent, you’ll estimate the next features you’ll try to deliver based on those.

It will take a couple of delivery cycles, but ultimately you’ll converge.

All who succeed in estimating, tried

As I mentioned at the start: it’s a whole paradigm.

It’s not deterministic, since it anyhow depends on humans and external factors you’ll have no control over.

Yet, over time, and applying the core concepts of agile (yes, read it – again, if you haven’t done that in a while), you will gain in predictability. And thereby in clarity of your communication to the external world.

Bragging right: after one year in that team with which I first worked in Scrum, we managed to plan the delivery of an entire new product within a 9 months lead time, before even dropping the first line of code, and the product was delivered right in time. Did it look precisely like the first sketches? No. Did it have a whole roadmap yet ahead? Yes. Did it solve the user’s problems? Yes. Achievement unlocked. It is possible, even though it’s hard and uncertain.

What is key in that story is that across the development and delivery, we could make decisions and trade-offs to determine how far we wanted to go on developing a specific feature, or simply if we wanted to develop it. Each time, we were back at “does that directly contribute to the value we want to deliver?”, “do we want to go for some sort of an MVP, or do we want to spend more time on refining this over that?”. We were aware of the impact of our choices, within a certain statistical predicatability.