If your team lives by the Agile manifesto or principles of lean start-up, then this may be your mantra: Build the product; don’t fiddle with your plans for it.
I’m surprised at how often people misinterpret this to mean that they must stop thinking and acting strategically.
Your agile shop is configured to ship small but valuable chunks of a product as quickly as possible. Because of this mindset, you can discover — and respond to wrong assumptions about your customer or unexpected market shifts. Do you need to have a long-term strategy in this shifting environment?
All gains, no pain?
The dexterity that Agile teams gain doesn’t come for free. Frequent course corrections can make such teams feel disoriented and deflated. The product managers who keep their crew pumped despite these uncertainties are masters of inspiration and focus. They paint a picture of how their collective work will alleviate a pain or spark opportunities. They are also able to keep the team focused on a sensible and concrete path to success. They are adept at sharing progress towards these goals, frequently with the help of product roadmaps.
Admittedly, roadmaps are not easy to produce or manage in the agile world. There is a lot of room for error. You may not even use one in your Agile world. Regardless of how you craft, communicate and manage your product strategy, don’t make these mistakes in the name of “speed” and “bias to act”:
Crafting the product strategy and roadmap in isolation from the whole team
A roadmap lies in the hands of its product manager. But to breathe life into it takes an army of smart people – engineers, product owners, designers, et al. Left uninformed, teams will question the items on this roadmap, ask why they were included, and protest that “their” items were left off. Arm your team with strategic answers by shaping the roadmap with their insight.
You may work in an organization where the teams are assembled after the product strategy and roadmap have been funded. If so, then create space in your plan to field questions from your team. More importantly, be prepared to make adjustments based on feedback from your team.
Responding too quickly to new client or market information
Teams adopt Agile to swiftly respond to new information. Fresh data may call for Agile teams to pause their work and absorb changes. Sometimes, however, the appropriate action is inaction or a delayed reaction.
Good product managers are tuned into channels of new market information. They are also considered approachable by partners, customers and their bosses — all of whom bombard them with requests for changes. The awesome ones are great at navigating these situations. They know when to peel their teammates away from building the product and when to let them stay on their path.
Discounting feedback from within the organization
Synthesizing data from market or customer but ignoring data from within the organization may be the most efficient way to lose support of your team. For instance, while in the throes of development, your engineers may hit an obstacle or be inspired by an idea. To triage this information and adjust the roadmap, if needed, is just as critical as responding promptly to other stakeholders.
Getting lost in the details
While at work on the roadmap, your team may be tempted to discuss the functionality of your product. Your team spends the majority of their time toiling on the details, so it becomes their default state. Lengthy dialogs about features and functionality, however, distracts from the purpose of creating or assessing your roadmap – which is to formulate a winning strategy.
Keep the team focused on questions, such as: are we targeting the right segment of users, are we prioritizing the needs that truly matter, what assumptions are we making, what hypotheses do we plan to test, what does the competitive landscape look like, etc.
In other words, the collective frame of mind should be to critically look at your strategy before you leap into the details of implementing it.
Not building any momentum
While designing roadmaps, Agile teams sway away from settling on timeframes. I recommend the opposite.
Yes, a team wrestles with ambiguities in the early stages of developing a product. They can’t imagine what shape the product may take. They may hesitate to commit to a launch date. You should accommodate these uncertainties in the first few phases of your roadmap by rallying the team behind a goal instead of a date.
After the initial stages, however, the outlines of your product become less blurry. At that juncture you should consider a taking a time-boxed approach where the phases of your roadmap are fixed in duration.
Product people take pride in — and love — the gratification of making things. The predictable rhythm of shipping stuff builds a momentum that keeps your team energized.
Don’t shift the launch dates — adopt a bias to ship instead.
- The implication: you have to quickly adjust the scope of work in response to unforeseen events.
- The benefit: you don’t commit the crime of exhausting your team by forcing them to chase a moving deadline.
This Japanese proverb best describes the risk product managers must manage in the action-packed world of Agile:
“Vision without action is a daydream. Action with without vision is a nightmare.”