I’ve touched on User Stories on several occasions, my favorite being Why Your User Stories Suck! Today I’m here to share with you a very common, yet very commonly overlooked, way to check each and every User Story on your backlog to see whether or not it’s really “ready” for your Dev teams. One of the most frequent causes of delays and slowdowns in most Agile implementations that I’ve seen comes from a lack of balance in the User Stories that the team is being given to deliver — stories that are too big, or which are dictates, or which just exist on the backlog because “someone asked for it”. What we need to do as Product Managers is to occasionally take a close look at each of our backlog items and make sure that they meet the INVEST criteria — Independent, Negotiable, Valuable, Estimable, Small, and Testable. If we do this simple gut-check on a regular basis, we’re far more likely to see our teams succeed and to reduce the amount of time wasted in long, drawn-out planning sessions.
Ah, the lull at the end of the year — that time between Christmas and New Year when things settle for the year (or half, depending on your FY) and the calendar rolls over into a new year, full of new possibilities and new opportunities. For Product Managers, this is the time when you settle your record for the past year and begin planning and preparing for the year to come — first quarters full of promise, second quarters full of marketing events, third quarters of adjustments, and fourth quarters of all-out execution. At least that’s my usual pattern – maybe yours is somewhat different. As the new year dawns, here are some suggestions on hitting the ground running in 2016, some exercises to get you back in the head space after a brief respite of the holidays…
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…