I’ve been working on B2B solutions for a very long time (dating almost all the way back to the turn of the millennia), and in that time I’ve come to realize that far too many applications try to be everything to everyone, and as a result really wind up serving nobody at all. You can see this in many product designs that try to capture all of the possible things that you could do at a given point in time, rather than leading you through a logical path, or showing you the most likely things that you may want to do. As much heat as I give the “ribbon” change that Microsoft introduced in Office a few (many) years back — conceptually, it was the right thing. It focuses you on the specific things that you need to do in some contextual space, without requiring you to remember which specific menu item someone decided to hide that option under. While the rollout was challenging, in my opinion, the approach really encapsulates a concept that I like to call “build for the novice, enable the expert”.
How to “Level Up” Your Product Management Skillset
A common theme in online discussions and forums around Product Management lies in how to level up our skills and be a better Product Manager. While there are a lot of different options available, just as there are as many different aspects of Product Management to focus on, there are some very specific areas that any given Product Manager can assess themselves in and decide what next steps they want to take to become a better Product Manager.
Balancing Agility and Strategy
One of the common struggles that Product Managers are faced with is figuring out how to be “agile” while still managing to a vision or strategy that’s been established by the Executives or Board. The important thing to remember is that strategy and agility are not in conflict with one another — if a strategy is properly formed, it’s a long-term view of where you’re going, and not specific enough to tie your hands when approaching the execution side of things. But that doesn’t mean that there aren’t tensions to be found in such a situation. Here are some thoughts on managing agility while executing against long-term plans…
A Product Manager’s Guide to Technical Debt
There’s always a fine balance to be found between making sure that your product is as buttoned-up as possible when it ships and the small (sometimes large) sacrifices that we have to ask our technical teams to make in order to just get the damn thing out the door. Within this gap lies the dreaded concept of “technical debt” – the ever-growing list of things that you know you probably shouldn’t have done or that you should have done, but that have way to the reality of getting product out to market. The good news? It’s not always bad. The bad news? Play too fast and loose with it and it will come back to bite you in the ass.
Measure What Matters
Many people are aware of the famous quote from Peter Drucker, “What gets measured, gets managed.” But what people don’t often consider is that what’s being measured and managed might actually not matter at all at the end of the day. When we measure things that don’t actually drive us to improve, we’re just acting like a cargo cult — going through the motions and expecting something magical to happen that never will. Instead of just picking some popular or standard metric, we should instead make sure that we understand what direction our measurements are going to give us, and what change they’re going to drive in our behavior or in our products. Only by being thoughtful and deliberate in our choices will we find the right metrics to use and rely on in our choices.
Here are a few things to watch out for and to take into account when considering what metrics we want to put into place…
INVEST in Your User Stories!
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.
New Year, New Priorities
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…