PM Desk Reference
Another product management book has been / is being released called the Product Manager’s Desk Reference - I just ordered my copy.
It’s fantastic to see all of the excellent resources being created and knowing that they are really going to help bolster the community and the amount of knowledge that’s out there about this (still) relatively new topic.
If you can, order yourself a copy! Congrats on the book, Steve!
Feature Plateau Trap
There is a big trap when managing an early-stage product. I like to call this the “feature plateau trap.”
When you have a product that is relatively new in the market there is a strong temptation to not stop building. It’s exciting to add new features - I totally understand. Everything appears sexy, and when you first start off, it’s easy to get caught up in, “well this next release is looking sparse compared to the last two or three - we better throw more stuff in there.”
As soon as you catch yourself, or your organization doing / saying this, you need a full stop.
There are some key things I think we can all take away from, and acknowledge about product management - many of which I have talked to death here. That is, you want to build products people want. You can’t build a product that is all things to all people - they don’t exist and attempts to create such a monster typically will fail.
So how do you know you have reached this plateau. For me, I like to constant evaluate against my roadmap. Where is the product today in comparison to where it was 6 months ago? What did we define as being important 6 months ago, and are those things in the product today? How is your current roadmap different from your previous 2 iterations on that roadmap?
If you start to see a lot of variance, you may be in starting to slide down a slippery slope.
Remember, folks - being market driven is so much more than responding to every feature request that comes in and making it a reality. Even when they are coming from really important people.
For example, would I act faster if Bill Gates asked me to implement a feature than I would if someone in Texas asked for a different feature? No.
But, would I take notice (not necessarily implement - but take notice) if both someone in Texas and Bill Gates requested the same feature? Yes. Much more so than a single opinion on what will make the product I’m managing the “best ever.”
But, this type of thinking has to start from the top. The PM can only do so much before they will be run down and just start writing requirements for whatever the CEO wants. You can push back and push back — but eventually, if the CEO wants the features they want and you aren’t willing to give them to him or her, they will find someone who is. That’s what makes this tricky.
All things aside, the feature plateau trap is very real and a very common problem in start-ups. There is a very fine line between building out a robust / complete product that solves a problem and just adding features. Maintain your perspective and don’t be afraid to put something new in, even when you aren’t getting the user feedback early on (because it’s hard to come by when you are building out your user base) and don’t be afraid to curtail feature development later in the product lifecycle.
It has to happen eventually, even if you look like an idiot for being the first to suggest it. You can’t always develop features at the pace you do the first year or so of the product’s existence. The thing has to breath, even if Bill G makes that “need to have” feature request. All of them should be evaluated equally and evenly and against the core product definition.
Otherwise, you are just building a group of features that happen to show up together and nothing cohesive.
Product Triage
Want to make sure you ship a quality product that the entire team is behind? When the time comes, make sure you know when to get out of the way - or, help folks push in to a situation where you can get out of the way and they can get their feedback and ideas in.
Having been through multiple large release cycles, I know that there is a time in each where an element of urgency and awareness kicks in. Everyone pushes towards a date, but sometimes that date falls by the wayside in favor of shipping something that’s got a high degree of quality. This is a good thing so long as it’s monitored. Folks dive in and start firing off things that need to be fixed / debugged / better / etc…
This is a great time. But know your place as the product person. You have to get out of the way and let the triage happen. Development will be just fine managing the intake. They are just as close (and in some cases, closer) to the product as you are and you’ll find 9/10 they will make good prioritization decisions on their own.
All you can do is make sure you stay on top of everything coming through your inbox / noted at meetings / discussed on calls and ensure things stay as consistent as possible. That’s your primary job during triage, aside from doing testing yourself. However, that can sometimes be hard since you’ve probably been super close the product throughout the entire release cycle, so do your best and provide development with as much as you can.
The other thing to watch out for is to make sure triage does not last too long. You don’t want to be entering the third week fixing things like, “this word should be that world” or “change color X to color y.” People will get demoralized really quickly and start to feel like the team is pushing for an un-attainable level of perfection. Don’t fall in to this trap.
If you see this type of thing start to happen, push back and get the release out the door. Unless there are critical things that continue to crop up after a period of weeks past the initially estimated ship date (at which point, your development process may need to be evaluated if this is happening regularly), you are going 100% fine getting it out the door. If you are running iterations, remember - that “critical” word or color change can happen in 2-4 weeks time without a problem.
It’s of utmost importance the product gets released.
So remember - ship early, ship often. But get out of the way of triage. A team of people (especially management and others who aren’t as close to the product as you are on a day-to-day basis) will call things out you didn’t think of and you don’t want to stifle their feedback at all.
Just make sure you are doing your job during this process / stage of the lifecycle. Keep things consistent across the product as much as you can, and make sure this doesn’t turn into a multi-week exercise in perfectionism.
Happy shipping!
Book: Art of Product Management
I suggest everyone go download a copy of the Art of Product Management. I’m making my way through it right now, and so far - it’s the best book I’ve read on the subject. Well done, Rich!
