5. Time on a Lean Roadmap

One of the biggest misconceptions of a lean roadmap is that it means there are no dates to be found anywhere. Unless you live in la-la land, product-led companies will still have to consider date-driven constraints or deadlines while using continuous discovery to ensure continued growth.

Using a lean roadmap just means that you’re stepping away from a format that insists that everything has a due date, which is unhealthy for any working team. 

The timeline, by its very format, gives everything on the roadmap an indication of a due date and an implied duration. As this guide showed earlier, there are a lot of problems with this. 

A lean roadmap can include Initiatives with dates and other project-related notes, where necessary. The key is to use these where necessary, and sparingly. 

After all, there’s no point in penalizing yourself by assigning a bunch of arbitrary due dates to work when it’s not helpful or needed. 

As much as possible, you should be looking at things in terms of the sequence of work to be done, and the most efficient way to use the resource and time you have. What’s the fastest, cheapest, least risky, and most effective way to solve the problems that are most important to your business right now? 

As a product team, you have limited time. The more time you can spend working in this mode, discovering and adapting to the problems around you, the more likely you are to solve the big, important problems that will make an impact on your business. 

When hard dates make sense

Sometimes things do come with hard dates though. These are things where you have to spend some time in project planning mode. After all, if you want to ensure you’ll get something out by a particular date, you or someone has to spend time upfront figuring out what’s in scope, who’s going to work on it, and how much effort it’s going to take from various sides of the business. Only then can anyone come close to giving an estimate on the effort and the delivery date. It’s a time and resource-consuming process, and should be done sparingly – you definitely don’t want to spend time doing it for initiatives that won’t ever see the light of day! 

If an initiative has a hard date, ask why. Sometimes there are good reasons, and other times, it’s worth pushing back. Good reasons include things that are externally driven, or strategically important. 

For example, if a new data privacy law is coming into play, you probably need to have a number of changes in place in order to stay compliant and legal. You could say it’s your company strategy (perhaps unwritten, but certainly there!) to stay legally compliant, and to not wrack up hefty bills for breaking privacy laws. If you’re working in finance or healthcare areas, you might find you’ve got more regulatory constraints to work around. That’s just one of the limitations. These spaces are harder, by their very nature. The upside is that there’s a greater barrier to entry. Once you’ve cracked the barrier, it’s harder for some new startup to come and build a replica and keep up, unlike in other more competitive and faster-moving spaces. The companies that are doing well in this space are the ones that can be as lean and efficient as possible or find creative ways to get around regulatory barriers as much as possible.

Other times, dates might be strategically important and driven by the market. For example, if you’re building for the education space, it might be pretty important that you get some work out by the beginning of September, or else the value can’t be realized until the following semester. Or if you’re in e-commerce, missing the Black Friday and Christmas rush would be detrimental to hitting your objectives. 

In these cases, you’ve got to put the forward planning in, as it’s an exercise in project management. If you want to maximize your chances of getting something out on time, you need to spend the time to make sure it’s a sound delivery plan upfront, or else be ready to skimp on quality or scope later on. 

Now, just because a team might have some hard dates baked into their roadmap initiatives, doesn’t mean they can’t be lean the rest of the time. You might be really lean most of the year, but you get into crunch mode to hit that Christmas release. Or you might think of yourself as completely lean, but every company gets sidelined by the occasional change in legislation. We all had a hard date to hit for GDPR, for example! It just means that work flexes around it, and with enough forward planning, these hard dates can be communicated on the roadmap, and shouldn’t be a surprise to anyone on the team.

The Agency Trap

The real problem comes when you start putting lots of dates on your roadmap. This month it’s a custom piece of work for one client, and next month it’s a custom build for someone else. Every month is ‘sold off’ to different commitments. It sometimes starts slowly, and seems innocent enough, or even like a good idea, if your team is getting paid for each of those finished pieces of work!

But what it means is that there’s no room for flexibility or discovery. Your team is constantly scoping, speccing, and delivering the next project, and as soon as that one is done, is starting on the next one. If new opportunities arise, they can’t change course and take advantage of them. If problems creep up, say growing tech debt and a declining conversion rate in your core product, the team can’t respond and fix that, as they’re committed to fixing whatever contractual problem first.

It wouldn’t be so bad if it was just one crunch a year, or the occasional legislative-related project that is just par for the course when running a business, but it’s a slippery slope to the Agency Trap.

The power of discovery

Why is discovery so powerful?

Discovery is at the heart of what product teams do. The very nature is to cast a wide research net to identify problems and hold back from committing to a solution. The product team then has a process of, essentially, guessing and checking to optimize to find the best solution that’s cost-effective, desirable to the market, feasible to build, and valuable for the business. It’s a process that can take years, and is messy, and doesn’t guarantee success by any stretch. But when it is successful, it pays off in spades. 

Contrast this with how agencies work. In an agency, a client identifies a problem for you and enlists your team to tackle the problem, and you and your team get paid for that piece of work. 

The biggest indicator of your ability to scale is to look at what it is that you actually sell, as a business. This determines whether you’re more of a product company or an agency. 

Agencies sell their time in exchange for money. This usually takes the form of client contracts and projects. Product companies, on the other hand, sell value that they create. 

Time is the one thing we can’t create more of, it’s the ultimate limited resource, and so agency-style businesses can only scale with more human resources – more people providing more of their time to the business. 

Product companies are able to create value, by investing time upfront, into a mix of products or services that can be resold again and again, without needing a directly proportionate number of humans involved to scale. 

This is why product companies can scale into such enormous tech giants, and fundamentally, why agencies can’t. Now, there’s absolutely no shame in building and running an agency. It’s a brilliant way to make money and create purpose, solve problems, and get paid.

But agencies don’t change the world. Product companies do! 

If you take a look at the companies storming the charts in the last decade, it’s tech companies who invest in scaling the product side of their business. 

Here’s a look at the S&P index, and how Netflix, Amazon, and Google are outperforming even the best of the best, with their product-minded approach.

Nearly every start-up company starts off with great intentions of following a scientific methodology of measuring, learning, and iterating until they’ve solved the most valuable problems in the world. 

But these go out the window in times of stress. Sometimes, “whatever we need to do to get to the next round” actually becomes selling time for money.

Agency work, done by a team who has otherwise configured themselves as a product team. It solves the immediate problem at hand, which is preventing the lights from going out.

But it also usually means that the real product work, discovering and cracking the interesting problems to solve, gets delayed and delayed. Because let’s admit it – making money and cashing checks is addictive. 

After all, ideas are nothing, it’s all about the execution right? That’s the power of delivery.

Except that every minute of time a client buys to have you work on their problems is a minute you can’t spend discovering and solving the bigger problems in the world.

There’s a chance that the client happens to identify a problem that’s big enough to apply to a wider market and you’re able to solve it at the same time as solving for the paying client, but those chances are slim. More often than not, you’re really just in delivery mode, and you haven’t just magically leapfrogged months or years of discovery. 

There are often clear signs that a company has veered into agency mode. They have a roadmap that’s pinned to work that needs to be delivered for clients, based on contracts or promises made in sales. And they have product people who spend more of their time acting like project managers than product managers. 

No deadlines? What this really means for your team

Having a roadmap that’s not driven by deadlines doesn’t mean your team doesn’t work to and respect deadlines. It’s just that those deadlines are reframed into something healthier. 

It means your team is no longer working to arbitrary deadlines, and are no longer feeling that wave after wave of deadline crunches that inevitably wear out your team and result in tech debt building up. 

There’s a vast difference between work that needs to be done by a date that was promised based on old estimates or made up by someone else, and an internally set goal for when work will be done, used to set expectations and drive motivation.

This is where tactics like timeboxing and internally set goals can be healthy.

Your team should still be setting their own pace, saying what they are working on, and what their rough effort and time estimations are, and sharing these with the people who are directly involved with the initiative. This helps to keep everyone on the same page and to understand where things might be getting stuck, so help can be conjured up at the right time if needed.

It helps to ensure your team isn’t getting stuck in rabbit holes, finding pockets of work that take proportionally way more work than expected. Having a timebox system and a habit of discussing where time is being spent makes sure that any rabbit hole can only go so deep, and so value doesn’t get lost in the process. 

Your development team isn’t motivated to get something out because the roadmap says it’s due on the 15th of next month. They’re likely more motivated because the sooner it gets out, the sooner their work will be seen and appreciated by others, and the sooner they can work on something new and fresh.

More importantly, your development team should be motivated by seeing their work regularly making a difference.

Rather than giving arbitrary deadlines, which result in tech debt and added stress, show the team how they are making a difference with regular and rapid iterations. Show them the impact they make on the problems you’ve outlined for the business, and for the real customers who interact with their code and designs.

You’ll get the best blend of fast iterations, without sacrificing quality along the way.