{"id":35176,"date":"2021-06-08T17:20:40","date_gmt":"2021-06-08T16:20:40","guid":{"rendered":"https:\/\/www.prodpad.com\/?post_type=pp_resource&p=35176"},"modified":"2022-09-01T15:45:48","modified_gmt":"2022-09-01T14:45:48","slug":"getting-your-team-on-board","status":"publish","type":"pp_resource","link":"https:\/\/www.prodpad.com\/resources\/guides\/ditch-the-timeline-roadmap\/getting-your-team-on-board\/","title":{"rendered":"Getting your team on board"},"content":{"rendered":"\n
\n
\n
\n
\n
\n
\"ditch<\/figure>\n<\/div>\n<\/div>\n\n\n\n
\n

6. Getting your team on board<\/h1>\n\n\n\n

You might see the reason and the need for a lean roadmapping process, but convincing your team is another matter. <\/p>\n\n\n\n

This section of the guide covers the most common stakeholders you\u2019ll encounter, and their likely objections to moving away from a timeline roadmap\u2014and tips on how to handle each.<\/p>\n\n\n\n

Convince Your Boss or Execs<\/h3>\n\n\n\n

Your boss, or your boss\u2019s boss, or the other executives floating around near the top of the organizational chart, tend to like to stick to their timeline roadmaps and often don\u2019t like having the format switched up on them. <\/p>\n\n\n\n

They also have some of the most weighty opinions in the company, so it\u2019s important to really understand where they are coming from, and be ready to assuage any fears of the change head on.<\/p>\n\n\n\n

The objections usually stem from a mix of a few aspects:<\/p>\n\n\n\n

The need for control<\/strong><\/h4>\n\n\n\n

One of the worst reasons for requiring a timeline roadmap is so that your boss can have a sense of control over what\u2019s being done and when, and can use it to dictate their own work requirements. While it feels<\/em> like they\u2019ve got control over things this way, what it actually does is slows down the work their team can actually deliver over all, and results in more tech debt building up, and usually in the wrong sorts of problems being solved. <\/p>\n\n\n\n

The alternative, the lean roadmap and OKRs, doesn\u2019t feel like it gives the same granularity in information about what\u2019s going to be delivered and when – because it doesn\u2019t! This can be disconcerting to a leader who\u2019s used to getting that sort of visibility. But when you open their eyes to the fact that the timeline roadmap was hardly ever going to be delivered on reliably anyways, and that it was so full of assumptions and buffer that it was holding your team back, they should see the risk<\/em> it was putting their business at by using that format. <\/p>\n\n\n\n

Insead, present the lean format of the roadmap and OKRs as an opportunity for giving control where it matters: the leadership of your business can outline what\u2019s important to the business, and make investment decisions about what to spend time on (eg. \u201cLet\u2019s spend this quarter on improving this key set of metrics\u201d)\u2014giving them complete control over the alignment of their team, while also providing the all important autonomy to their team to solve the problems in the best way possible. <\/p>\n\n\n\n

For the tricky execs in your life, appeal to their investment sense – talk about the risk they are putting the business in by moving more slowly than the competition, the wasted resources that they could see put to better use if they worked in a leaner way, and the rewards they\u2019ll reap from having a platform that needs less constant rework in the future. <\/p>\n\n\n\n

They\u2019ll see that giving up this false sense of control is worth it for the benefits the business will reap at the end!<\/p>\n\n\n\n

The wrong business model<\/strong><\/h4>\n\n\n\n

Sometimes the problem stems from the fact that the business is set up to make money in the wrong way, and you\u2019re being asked to work within awkward or impossible constraints as a result.<\/p>\n\n\n\n

This most often happens when you’re stuck in the Agency Trap. Companies stuck in agency mode are those who regularly take on client or sales driven commitments, effectively selling off their development time to the highest bidder, in order to do custom work or deployments, or other things that are designed to satisfy the needs of that specific client, but aren\u2019t part of a larger product strategy. In these cases, the business is committing to projects and giving itself arbitrary deadlines, while not creating space for important discovery work to happen. These sorts of projects aren\u2019t detrimental as one-offs, in most cases, but many companies have a habit of taking on wave after wave of these commitments. After all, it\u2019s hard to turn down the promise of instant cash for your work!<\/p>\n\n\n\n

If you find yourself in this position, it\u2019s important to call it what it is. You\u2019re not building a product, you\u2019re working in an agency. There\u2019s no shame in having an agency model, as it\u2019s a great way to make money and solve interesting problems. But agencies don\u2019t scale in the same way product companies do. Each minute of time committed to solving a one-off problem for a client is time that can\u2019t be spend discovering and solving the bigger, juicier problems that launch product companies into the stratosphere. <\/p>\n\n\n\n

The tension with your exec team comes when they expect results like a product company, with hockey stick growth and the ability to keep up with even the hungriest competitors, while asking you to keep time like an agency, delivering work that\u2019s been fed to your team from the sales end of the organization. <\/p>\n\n\n\n

This is the result of so much tension in teams, and so many product company failures. <\/p>\n\n\n\n

If you spot that you\u2019re in the agency trap, speak up. The company needs to decide where it wants to head in the future, and align its processes accordingly, and doing so begins with highlighting the problem.<\/p>\n\n\n\n

External pressures – investors or customers<\/strong><\/h4>\n\n\n\n

Occasionally, the pressure you\u2019ll be feeling to show dates on your roadmap are actually transferred pressure, from outside forces\u2014namely investors or customers.<\/p>\n\n\n\n

Your boss is trying to pin things down so they can report a clear picture outwards.<\/p>\n\n\n\n

As with any of these requests, it\u2019s important to understand what they\u2019re trying to achieve, and help bring them on side.<\/p>\n\n\n\n

Investors<\/h5>\n\n\n\n

For investors, any decent investor doesn\u2019t actually care about your timeline roadmap. A good investor invests in the team, and a good team should be able to demonstrate that they are smart and resourceful enough to win, even in a fast changing market. A roadmap that simply outlines a bunch of feature release dates doesn\u2019t tell them much. In fact, if the investor wanted that<\/em> roadmap of stuff so much, they could pay an agency to go build it for much less than they are investing in the team. The team should be able to know their market, and react to movements from customers, competitors, partners, and other forces, and pick a path that\u2019s most likely to result in the biggest returns for themselves and their investors. A lean roadmap with meaningful objectives can express this ability much more effectively than a timeline roadmap. Instead of the timeline roadmap, use OKRs and the lean roadmap to articulate what the product strategy is, and what sort of opportunities and gotchas your team is accounting for and ready to flex around, and you\u2019ll find that you\u2019ll likely meet your investors\u2019 needs for understanding how they\u2019re investing their money in a sound strategy. <\/p>\n\n\n\n

If not, do you really want to take money and give control to an external person or organization who wants to lock your development efforts down to what you thought was a good idea in month one?<\/p>\n\n\n\n

Customers<\/h5>\n\n\n\n

Unless you\u2019re operating in an agency model, where you\u2019re committing to work for clients ahead of time, it\u2019s important to remember one fundamental thing: Your customers are buying your product or service as it exists today<\/em>. Your roadmap isn\u2019t meant to be a sales tool or a way to promise things that haven\u2019t been built yet, but rather is a tool in your discovery belt, to help you assess what sorts of problems you might solve for in the future. Just like you might show your customers prototypes of upcoming designs, but make no promises of what the final version will look like, or even that it will see the light of day, your roadmap is a prototype for testing your product strategy with customers, to see if your plans resonate or if you should consider making adjustments before you get too committed. <\/p>\n\n\n\n

As such, your roadmap shouldn\u2019t include future dates that are visible to customers. You don\u2019t know if things are going to be launched, let alone when! <\/p>\n\n\n\n

You might get pressure from your boss to show a roadmap to customers, and if so, stick with a lean format that is centered around your objectives and the problems you want to check are worth solving, and don\u2019t go into details about features or their launch dates. <\/p>\n\n\n\n

Convince Your Sales Person<\/h3>\n\n\n\n

Your salesperson is often the first person breathing down your neck, asking when something is going to be delivered. <\/p>\n\n\n\n

This is either because they\u2019re purely excited to see what\u2019s coming out next and when they can start selling it (Fair enough! This is where your expectation management skills as a product manager come into play, to keep the excitement levels in check), though sometimes it\u2019s because they\u2019ve <\/em>made a commitment (or cornered you into conjuring up a rough estimate that\u2019s now held as The Truth) and now are expecting you and the developers to hold it up. <\/p>\n\n\n\n

This one gets awkward. If you\u2019re seeing lots of this, it might be because your company\u2019s business model (see above) isn\u2019t set up for the product work you thought you had signed up for, and it\u2019s pitting you against your sales team, who are being allowed to lead the way with gathering the clients and requirements for work. <\/p>\n\n\n\n

It also might be because your sales team isn\u2019t equipped, or frankly, good enough. If you\u2019re a product company, the thing for sale is the product that exists today. Not some future product that you haven\u2019t built yet. So the sales people need to either sell what you have, or you need to have some tough conversations about why your current product is unsellable. <\/p>\n\n\n\n

If it\u2019s truly unsellable, you\u2019ve hired a sales team too soon. Those sales people are either not needed in their roles, or should be redeployed as research agents, helping you to figure out what would<\/em> sell.<\/p>\n\n\n\n

Unsellable is a harsh word though. A lot can be done by really understanding how your product works and who it best solves problems for, and positioning it really well to attract the type of customers who want or need your product as it exists today. <\/p>\n\n\n\n

And more often than not, your current product is totally sellable, at least in some markets. It\u2019s just that it was easier<\/em> to make the sale when the salesperson could throw in a commitment to adjust it this way or that way. <\/p>\n\n\n\n

The problem is, those commitments are leading your company down a path of building a Frankenstein of a product, designed by a committee of clients, and never really carving out a product that meets its full potential. <\/p>\n\n\n\n

Work with your sales team to equip them to sell what you have today, and educate them on the purpose of the lean roadmap: It\u2019s not a promise of future feature launches, but a way to test and understand more about what the market needs from your product in the future.<\/p>\n\n\n\n

Sales has a huge and active role to play in product-led organizations, and they will be your biggest product advocates if given the right tools. Bring your sales team along for the journey, and show them how the product-led way will bring the whole company huge amounts of success. <\/p>\n\n\n\n

Convince Your Marketing Team<\/h3>\n\n\n\n

The marketing team is also often beholden to the product development team and their work: after all, how can they plan their campaigns, if they don\u2019t know when something\u2019s going to go live?<\/p>\n\n\n\n

The key here is to separate your hard launches from your soft launches. This is good practice anyways, as a soft launch gives the team a chance to check and test features in various states of \u2018live\u2019 before really telling the world about it. Nowadays, there are tons of resources and tools to help manage soft launches, like feature-flagging software or A\/B testing suites. <\/p>\n\n\n\n

The goal here is to remove the dependency that the marketing team has on the development team. After all, development is more of an art than a science, and as we all know, timelines, even the best estimates we come up with, regularly slip. <\/p>\n\n\n\n

Rather than trying to plan two projects that overlap and end at the same time (the development ship date, and the marketing campaign launch date), simply kick off the marketing campaign work only after the development team has shipped. Once the feature is in soft launch mode, the market team has all the time in the world and<\/em> all the access they could possibly want, to make their campaign a total success.<\/p>\n\n\n\n

If they need 6 days, or 6 weeks, or even 6 months, to plan the perfect campaign, that\u2019s fine – they can begin planning the day the feature gets to the soft launch phase. While that feature is in soft launch phase, they have complete access to the feature, unlike what they could have possibly gotten before. For example, they could get videos and screenshots of the feature in use, either in a feature-flagged internal environment, or perhaps with some of their Beta testing customers. They can get those Beta customers to give testimonials, and use those to build up the materials they\u2019ll need for the campaign they\u2019re planning. <\/p>\n\n\n\n

This is a far cry from having to use the design mockups and wireframes that went into<\/em> development as their marketing collateral, or trying to get a peek at the final coded version before it goes live, and hoping that they are still marketing something that looks pretty much the same. <\/p>\n\n\n\n

It also massively de-stresses the whole situation. No worries about wasting time or resources trying to coordinate launches, or sweating over getting something live before the billboard ads go live. <\/p>\n\n\n\n

In the meantime, while the developers are building the next big thing, the marketing team should be planning and launching campaigns around previous elements of the product that are already built, in various stages of soft launch, and moving towards hard launches. <\/p>\n\n\n\n

This isn\u2019t to say that marketeers shouldn\u2019t be involved in product development earlier on, however. The whole team has so much to offer to a good product process, and the marketing team can help gather insights, inform on market viability, determine positioning and messaging for potential ideas, and more. Get your marketing team involved in the product process way up front, but be sure to separate their campaign planning so that they don\u2019t depend on your development launches landing on specific dates.<\/p>\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>