{"id":9506,"date":"2021-03-17T12:34:20","date_gmt":"2021-03-17T12:34:20","guid":{"rendered":"https:\/\/www.prodpad.com\/?post_type=pp_resource&p=9506"},"modified":"2022-09-01T15:47:22","modified_gmt":"2022-09-01T14:47:22","slug":"time-on-a-lean-roadmap","status":"publish","type":"pp_resource","link":"https:\/\/www.prodpad.com\/resources\/guides\/ditch-the-timeline-roadmap\/time-on-a-lean-roadmap\/","title":{"rendered":"Time on a lean roadmap"},"content":{"rendered":"\n
\n
\n
\n
\n
\n
\"ditch<\/figure>\n<\/div>\n<\/div>\n\n\n\n
\n
\n
\n

5. Time on a Lean Roadmap<\/h1>\n\n\n\n

One of the biggest misconceptions of a lean roadmap<\/a> 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.<\/p>\n\n\n\n

Using a lean roadmap just means that you\u2019re stepping away from a format that insists that everything<\/em> has a due date, which is unhealthy for any working team. <\/p>\n\n\n\n

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<\/a>, there are a lot of problems with this. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

After all, there\u2019s no point in penalizing yourself by assigning a bunch of arbitrary due dates to work when it\u2019s not helpful or needed. <\/p>\n\n\n\n

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\u2019s the fastest, cheapest, least risky, and most effective way to solve the problems that are most important to your business right now? <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

When hard dates make sense<\/h2>\n\n\n\n

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\u2019ll get something out by a particular date, you or someone has<\/em> to spend time upfront figuring out what\u2019s in scope, who\u2019s going to work on it, and how much effort it\u2019s 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\u2019s a time and resource-consuming process, and should be done sparingly – you definitely don\u2019t want to spend time doing it for initiatives that won\u2019t ever see the light of day! <\/p>\n\n\n\n

If an initiative has a hard date, ask why. Sometimes there are good reasons, and other times, it\u2019s worth pushing back. Good reasons include things that are externally driven, or strategically important. <\/p>\n\n\n\n

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\u2019s 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\u2019re working in finance or healthcare areas, you might find you\u2019ve got more regulatory constraints to work around. That\u2019s just one of the limitations. These spaces are harder, by their very nature. The upside is that there\u2019s a greater barrier to entry. Once you\u2019ve cracked the barrier, it\u2019s 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.<\/p>\n\n\n\n

Other times, dates might be strategically important and driven by the market. For example, if you\u2019re 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\u2019t be realized until the following semester. Or if you\u2019re in e-commerce, missing the Black Friday and Christmas rush would be detrimental to hitting your objectives. <\/p>\n\n\n\n

In these cases, you\u2019ve got to put the forward planning in, as it\u2019s 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\u2019s a sound delivery plan upfront, or else be ready to skimp on quality or scope later on. <\/p>\n\n\n\n

Now, just because a team might have some hard dates baked into their roadmap initiatives, doesn\u2019t mean they can\u2019t 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<\/em> 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\u2019t be a surprise to anyone on the team.<\/p>\n\n\n\n

The Agency Trap<\/h2>\n\n\n\n

The real problem comes when you start putting lots of dates on your roadmap. This month it\u2019s a custom piece of work for one client, and next month it\u2019s a custom build for someone else. Every month is \u2018sold off\u2019 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!<\/p>\n\n\n\n

But what it means is that there\u2019s 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\u2019t 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\u2019t respond and fix that, as they\u2019re committed to fixing whatever contractual problem first.<\/p>\n\n\n\n

It wouldn\u2019t 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\u2019s a slippery slope to the Agency Trap<\/a>.<\/p>\n\n\n\n

The power of discovery<\/strong><\/h2>\n\n\n\n

Why is discovery so powerful?<\/p>\n\n\n\n

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\u2019s cost-effective, desirable to the market, feasible to build, and valuable for the business. It\u2019s a process that can take years, and is messy, and doesn\u2019t guarantee success by any stretch. But when it is successful, it pays off in spades. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

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\u2019re more of a product company or an agency. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

Time is the one thing we can\u2019t create more of, it\u2019s 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. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

This is why product companies can scale into such enormous tech giants, and fundamentally, why agencies can\u2019t. Now, there\u2019s absolutely no shame in building and running an agency. It\u2019s a brilliant way to make money and create purpose, solve problems, and get paid.<\/p>\n\n\n\n

But agencies don\u2019t change the world. Product companies do! <\/p>\n\n\n\n

\"The
Product-led companies are leading the way<\/figcaption><\/figure><\/div>\n\n\n\n

If you take a look at the companies storming the charts in the last decade, it\u2019s tech companies who invest in scaling the product side of their business. <\/p>\n\n\n\n

\"The
Tech companies are storming it<\/figcaption><\/figure>\n\n\n\n

Here\u2019s 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.<\/p>\n\n\n\n

\"Good
Product-led intentions don’t always last<\/figcaption><\/figure>\n\n\n\n

Nearly every start-up company starts off with great intentions of following a scientific methodology of measuring, learning, and iterating until they\u2019ve solved the most valuable problems in the world. <\/p>\n\n\n\n

But these go out the window in times of stress. Sometimes, \u201cwhatever we need to do to get to the next round\u201d actually becomes selling time for money.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

But it also usually means that the real product work, discovering and cracking the interesting problems to solve, gets delayed and delayed. Because let\u2019s admit it – making money and cashing checks is addictive. <\/p>\n\n\n\n

After all, ideas are nothing, it\u2019s all about the execution right? That\u2019s the power of delivery.<\/p>\n\n\n\n

Except that every minute of time a client buys to have you work on their problems is a minute you can\u2019t spend discovering and solving the bigger problems in the world.<\/strong><\/p>\n\n\n\n

There\u2019s a chance that the client happens to identify a problem that\u2019s big enough to apply to a wider market and you\u2019re able to solve it at the same time as solving for the paying client, but those chances are slim. More often than not, you\u2019re really just in delivery mode, and you haven\u2019t just magically leapfrogged months or years of discovery. <\/p>\n\n\n\n

There are often clear signs that a company has veered into agency mode. They have a roadmap that\u2019s 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. <\/p>\n\n\n\n

No deadlines? What this really means for your team<\/h2>\n\n\n\n

Having a roadmap that\u2019s not driven by deadlines doesn\u2019t mean your team doesn\u2019t work to and respect deadlines. It\u2019s just that those deadlines are reframed into something healthier. <\/p>\n\n\n\n

It means your team is no longer working to arbitrary <\/em>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. <\/p>\n\n\n\n

There\u2019s 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.<\/p>\n\n\n\n

This is where tactics like timeboxing and internally set goals can be healthy.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

It helps to ensure your team isn\u2019t 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\u2019t get lost in the process. <\/p>\n\n\n\n

Your development team isn\u2019t motivated to get something out because the roadmap says it\u2019s due on the 15th of next month. They\u2019re 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.<\/p>\n\n\n\n

More importantly, your development team should be motivated by seeing their work regularly making a difference.<\/p>\n\n\n\n

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. <\/p>\n\n\n\n

You’ll get the best blend of fast iterations, without sacrificing quality along the way.<\/p>\n<\/div><\/div>\n\n\n\n

\n
\n

In this Ditch your Timeline Roadmap<\/a> guide:<\/strong><\/h4>\n<\/div><\/div>\n\n\n\n
  1. What is a Product Roadmap<\/a><\/strong>