Browsing Tag

release plan

You Don’t Really Own Your Roadmap

Here's your sign!Sales people hate looking stupid. Unfortunately, we often put them in positions where they look very stupid by changing plans and roadmaps, which is our own fault. How do you keep the trust of your team when your business, roadmap, and customers are shifting in the sands around you?

There are lots of reasons that plans change, some good and some bad: the Market shifts, the competition makes a play, or the company dosen’t hit its goals and has to layoff developers, which pinch your resources. All of these create a refactor in your roadmap.

There are several tactics you can use to lessen the impact of changes to The Plan. I’ve written in the past about the importance of separating your Roadmap from your Release Plan. This simple change, and the cultural impact at the Executive level down to the developer level of thinking that “a product/feature on the Release Plan is locked in and cannot be changed” is huge. Remember that Release Plan’s mean that the product or feature’s release is imminent and committed – your Release Plan should never cover >6 months.

Also, realize that you don’t really own your roadmap. The best you can do with the roadmap is plot a general direction for a product or service, but when it comes down to it, the Market and the Business own the roadmap. The Roadmap is not yours; you are the steward of the Roadmap. I see products and companies fail all the time because they set their roadmap and expected the Market to bend to them; it doesn’t work that way.

One-off deals can also derail the roadmap. In a smaller company where there is immediate revenue pressure, the allure of a special deal that “just needs this one feature” is huge. Are you ready to turn down a million dollars in revenue? Most Executive teams are not. Be able to illustrate how any proposed feature or product changes to your roadmap delay or eliminate your entrance into new markets or buying personas. That changes the special deal conversation from emotion-based to data-based.

New Development VP’s also have a tendency to take roadmaps off course. The reason: they love changing technology architectures. I carry a cross on this one since I’ve been burned before, from a CTO who changed the team from Java to .NET…which meant retraining some developers, dumping other developers, and hiring new developers. We lost 12-18 months just spinning – it was stupid!

When you see the VP of Development pushing for a change in development platform or underlying technology, drill closely into the details of why. Most Dev VP’s aren’t dumb enough to say “it’s because it’s a fad” or “because I want to get quoted in CTO magazine!,” and they will come up with legitimate sounding reasons why the old platform sucks and we really, really need this new one. You need to provide the voice of reason – with today’s technology, you can build an adapter to and from almost any technology without having to rip up your entire platform. If it’s that strategic to change your platform, the company should be able to justify the expense of building a parallel platform next to the existing one without disrupting current development.

One type of project that can be completely immune to external forces taking them off roadmap is the open source project. Since developers in this model often develop for themselves and not for the Market, oftentimes they don’t care what their users are asking for. Other open source projects are more flexible to the wants of their Market and do adjust their plans.

What other reasons pop up for taking you off roadmap, and how do you combat them?

Development: Leave Us the $Foo Alone!

Jeff Lash has a good post up about Delegating. There are some interactions you need to have – like regular tradeoff meetings with Development. As a general rule, programmers hate meetings. A lot of that has to do with the fact that prior to you, they had some “Marketing” airbag pull them into blahfests about “sustainable competitive advantages” and how we can get a that feature to “go viral.” Now meetings from Marketing (and by proxy Product Management) are dismissed as a waste of time.

Lead Architects in are alpha dogs. There’s only room for 1-2, otherwise they start to piss on each other’s territory and talk about how so-and-so isn’t pulling their weight or how they had to clean up the other’s code. Design planning and software requirements are viewed as nice-to-have’s, and often as Product Management you’ll find yourself in a situation where you’re bringing requirements to Development only to hear “Oh yeah, I heard you were working on that so I already built it.” Great! It’s done, on to the next feature…uhhhhh, no.

What you’ll find is that you got a half-implementation based on:

  1. What was easy for the developer to do over the weekend
  2. What was interesting for the developer
  3. What is based on the developer’s (incomplete) interpretation of the customer’s problem

When you push back on the implementation you have to do it gently to avoid bruising ego’s. Engineering’s usual M.O. is to say “this is what we’re offering, to do your (complete) implementation will take<$ridiculous_timeframe>.” Besides, who is going to call B.S. on the development estimate – they’re the one’s making it! Fox, meet hen house!

There are two ways around this problem. First you need to have the fortitude to call Engineering’s bluff. If you get a time frame of 6 additional months, say “OK. That’s fine. I’ll need to see a detailed schedule so we can determine what resources we need to hire to help you.” If the full implementation is that important, you should be able to drive a business tradeoff to get the resources to make it happen.

Second, you can avoid the problem in the first place with proper planning. Once you approve a product onto your Release Plan, form a Core Team and pull the lead developer onto it. He/She will grumble about the meeting but stay firm – you need the Core Team to drive tradeoffs and get ahead of the prototype that they’re going to build.

Often, Developers project verbal and non-verbal signals that meetings are inefficient uses of time, that they don’t need to be there, or that they could be doing “more important” work. Basically they are saying: “Leave me the F alone!” I’ve found that they feel that way because they don’t interpret their time as valued by Product Management or Marketing, or they don’t feel like PM has a good handle on the tradeoffs that need to be made. Whenever I get these signals from a Developer, these are my tactics:

  1. Be sure to start the meeting with an explicit statement about why we are here, what the goals are, and the expected output of the meeting
  2. If you start getting verbal or non-verbal signals from a Programmer (disinterested, checking email, sighing, rolling eyes, pacing around the room, etc), stop the meeting immediately and address the issue – “Joe, I keep hearing you sigh and roll your eyes, do you understand why we are here? Do you understand why we need YOU here? Is there something else that you need to be doing at this moment?” I’ve actually been in meetings where the developers had stopped working on a critical hotfix, without telling us that we were holding up their work, and were glaring at PM for running the meeting! Enable people to have a voice, because they might not speak up…
  3. If Joe agrees with the purpose of the meeting and his role there, and is still offering bad non-verbals, actively engage him with open-ended questions, much like you’d do on a customer interview.
  4. After the meeting, follow up one-on-one to talk about the importance of the design and tradeoff process, emphasizing that a good design solves a more complete problem set and reduces wasted work in Development. The only thing Developers hate more than meetings is doing work and having it go to waste or get mothballed.

…because it’s Friday, here’s an Office Space clip that always makes me think of Product Management and grin: