Many companies struggle with the challenges of reconciling the need for strategic planning and the desire to execute in an “agile” or Agile fashion. Generally speaking, this is because they’re stuck with the perspective that a “roadmap” must be a set of promises regarding what’s to be delivered, and not merely a strategy that will and must change over time. Being “agile” requires that we accept the unknowns in the world — and what’s more unknown than what the market is going to look like in 2 years? Therein lies the folly in trying to perform traditional roadmap planning and expecting to be able to be “agile” in your execution. But, there are some easy ways to change your perspective on roadmaps and maintain the balance between strategy and execution.
As companies transition from traditional, more waterfall-oriented approaches to their products, they often struggle with understanding how agile practices fundamentally change the ways in which they need to plan and develop their product roadmaps, both for internal use as well as for discussion with key customers and market prospects. The old-school method of assigning specific features on a quarterly basis just fails the smell test when you’re claiming to be agile — the whole concept behind being “agile” is that you’re accepting that you aren’t some Oracle of Delphi, and that you really can’t predict the future with any certainty.
This doesn’t mean, however, that you can’t create a strategic plan that involves a product roadmap to put your investors, teams, and customers at ease. It just has to look different and to focus on the things that you can know, while allowing for the flexibility necessary to truly be agile and market/customer-driven.
I invited several of my friends in the product management, marketing, and strategic consulting fields to provide a little guest content to mix things up here on the Clever PM blog. Today’s installment comes from my long-time friend and current growth hacking specialist Jason Pedwell, who blogs on his own website, LiftDad.com. He’s here today to talk to us about why your customers don’t actually care about your features…
Now, I’m not suggesting that you could sell someone a car without the steering wheel, but nobody cares about it – a steering wheel is table stakes to enter the game of building a car. All cars have a steering wheel, so it is expected.
There is something intangible customers care about, but it’s not about having the most or best features.
We’ve all been there — we’re talking about our upcoming projects, discussing possible timelines and resource allocations, working to align our tactical work with the company and product strategy, when it hits you like a brick thrown through your living room window in the middle of the latest Game of Thrones episode:
So, where’s the project plan?
And that’s where it goes downhill. Because we all know that what’s usually meant by “project plan” is some extremely detailed, well-defined, cascading graphic from hell known as the Gantt chart. It’s been the go-to standard for project management and project planning for decades.
And it needs to die. A miserable, screaming, Melisandre-putting-it-on-the-fire-for-the Lord-of-Light death.
In a prior installment, I discussed how the concepts of Newton’s First Law of Motion might be understood and adapted to the world of Product Management. Since writing that piece, I thought it would be interesting to create similar pieces for the other two Laws that Newton originally expounded. While this sounds kind of easy — and it is for the First and Third laws — the Second Law was troubling me for a bit.
Then it hit me — in Product Management, we’re constantly working to push forward new ideas, and to ensure that the current plans fit with the state of the world, the market, and of our customers. And we’re always doing so from a place of influence rather than authority.
So, if you look at it from that perspective, nearly everything that we do is a matter of force, which under Newton’s Second Law is the product of mass and acceleration…
Over the course of my career, I’ve had the chance to work with a wide variety of tools and methods to document how something should work, what user goals are, what the workflow should be, and generally how a user gets from point A to point B and beyond. Throughout all that time, I’ve noticed a definite pattern in when, how, and where you get the most valuable and actionable feedback. The key is to track the feedback that you get from your stakeholders along a spectrum from ideation and paper documentation, all the way through to delivery, and figure out at which point those groups provide the best, most actionable feedback.
There’s not a Product Manager alive who hasn’t seen the traditional project management pyramids or triangles — it’s a very common trope of the business, focusing on Time, Scope, and Resources as the “pivot points” for hitting deadlines, or the common line of “Good, Fast, or Cheap — pick two.”
The simple fact is, in nearly every organization, there is no pyramid or triangle. There is only Scope. [Read more…]