How Product Decisions Work
It’s all very simple.
But I thought I would write-up a quick post in case there are those of you out there struggling with how to either a) make product decisions or b) think a PM you are working with is taking too long.
The bottom line is this: product decisions are highly complex. In some organizations they take months to make - in others (start-ups for example) days or weeks. But that’s because they are hard choices to make and require gathering consensus. You can’t spitball your way to a successful market-driven product.
You also can’t play pump & dump strategies with features - it doesn’t work long-term (even if it you think it will) and it creates far too much make work for all of those involved.
You will end-up with a product that just is an amalgamation of cruft from all those failed attempts (regardless how small and meaningless they seem - this is a very slippery slope and once it starts) unless there are appropriate reasons in place for each of them and strategies to deal with them when they work and when they don’t work.
There is no argument with this. It happens all the time - so just stop it if you see it happening or starting to happen. It always, always ends badly.
Product decisions, when the inputs have been built up and are being used effectively take everything in to account, have the full benefit of the user in mind while still taking alignment with the overall problem and vision in to account.
The product definition, corporate strategy, user feedback, competitive analysis, analytic data, metrics, win/loss, industry research, and just ideas that are floating around in general, etc, etc… These all need to be consulted as you go. It’s the product manager’s job to track all that data and use it to make effective choices.
Again, trust me - you can’t rely too heavily on one or the other - they will always lead you astray when it comes to product. For example, if you follow what users say exactly you will end-up with features that dead-end because user’s won’t think things through entirely.
A great example is internal ideas. Everyone always knows what’s going to make the product successful - and they are always highly passionate about it. But remember, while they idea may make sense and see really great at the outset, once you start to attempt to map it against other market data, it may not align with what the market tells you.
And you ALWAYS trust the market before co-workers and yourself.
Another example is analytics. You look too hard at where users are clicking, and you may miss the underlying fundamentals - for example, maybe you have no value proposition. Analytics won’t tell you that and you could arrange a page and bucket test it now until the cows come home and it still won’t work.
When you are assessing a priority to give to something, or how to make something better, you need to take all these factors in to account.
Yes, there are circumstances where slapping stuff together may work - but ad-hoc product development, the further you go in the lifecycle, just doesn’t cut it. If it did, everyone would be able to make these decisions and know how to filter out all the noise from the data that has been gathered.
Everyone doesn’t.
So, there is an easy fix to all of this - just talk before taking action. It doesn’t have to be day long meetings - just 5-10 minutes. You’ll be amazed at what you discover is actually being done behind the scenes to improve a product when you have a PM who knows what they are doing.
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!
Changing Product Direction
From time to time you need to tweak and change your product’s direction. Essentially, this means that you’ll be trying to work in new things, but also change existing things at the same time.
So, how does this impact the organization? Well, in a lot of ways. Namely, it’s the swapping and changing of certain key features that currently exist and changing those out for new features that better match the revised vision.
Really, this is just all about one thing: alignment. Competitors will come and go, but to make a product truly great, it has to align to your overarching vision - the identification of the solution for how to solve your chosen market problem(s).
Now, in theory this is very simple. Turn some knobs here, change out some labels over there - easy, right? Well, not really.
Successfully shifting a product from one chosen strategy to another (regardless of the size of that shift) can face some adversity within the business. People are inherently adverse to change, which is really where the challenge lies. Everyone will be OK with things until features start to get severely changed (or, in many cases, dropped) because they may feel things are working out really well as they are - or maybe, the didn’t understand that a product strategy shift would mean so many new and/or different things.
So, how can you as a product manager help to ease this transition to the new strategy you may have created (or not)? You kind of can’t - just let it run it’s course. Clear things up for people as much and as regularly as possible.
The other thing you can do is communicate early and often. This is something I struggle with because I always ask myself, “why are people interested in what I have to say?” I am slowly coming to the realization that it has nothing to do wit me as a person, but me as a product owner. If you are in charge of the product (and thus, the associated strategy) that’s changing, everyone will be interested in what you have to say.
Why? Because it directly affects them and what they do.
Make the change - buy in to that change. Execute it. Remove features, change features - sometimes more drastic changes are required. It will make the product feel awkward. It will feel drastic, and in some cases downright wrong. But you have to buy-in and you have to commit. Otherwise, you are failing to properly execute the product strategy you believe will make it successful in the end.
Don’t Get Discouraged
When you are in the thick of things, it’s easy to lose sight of the bigger picture. That picture may be 1 month, 3 months, or 6 months (plus!) away, but people (myself included) can get wrapped up in not being perfect, seemingly not doing enough, or thinking you are doing things wrong.
You can’t get worried. Well, you can - if you don’t have certain key things in place.
It’s easy to get all down and razzled if you see constant new “competition” popping up all over the place every week, or other products getting press yours isn’t. Quite frankly, it’s just not worth it. Take it as inspiration, learn what you can from it, and press on.
Remember - it comes down to a couple of things. Are you solving a problem people have, and does your product add some good value while solving it? If everything from the top-down (I’m not talking organizationally, really) is aligned, that means you have placed your bets and can just worry about execution.
It’s all about placing a bet and executing. “Wow” features and “silver bullets” are not what you rely on to build successful products. It’s all in the fundamentals. Those things may come along, or maybe you are developing one without even realizing it - but you can’t hold things up waiting for those ideas to come along.
You need to just do a few things really well. In fact, things I’ve already mentioned:
- Ensure you are solving a problem
- Align things form top to bottom
- Execute — quickly and with confidence
This “top-down” stuff I speak of is from the vision / problem identification, to the roadmap, to the requirements, to each release being pushed out the door. There are a few strategies that go into shipping a product which I may detail in other posts (for example, is this product brand new? does it already exist? at what stage of the lifecycle is it?), but for now take solace in having a clear vision to which all decisions are baselined.
If you are focused on something (almost obsessively so) you are doing everything right. Of course the organization could fail - but all you can do is pick a problem and go after it as hard as you can. You can’t solve all of the World’s problems by building 15-20 products at once.
Remember — it’s all about being good enough. Well, in most cases. Tony Stark may have a problem doing that, but start-ups building Web applications should not.
