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.
Watch for Flags
Having done a few start-ups and having some interesting experiences (OK, very interesting experiences) along the way, there are a few red flags I keep my eyes peeled for.
Your mileage may vary, and I’m totally not trying to hit all of them here - just some stuff I’ve learned to watch for in the past, and I thought I’d jot them down.
Requirement Delivery Time
In product management, there is a pretty big flag that I keep my eye on regularly — time to deliver requirements per release. If you are looking at regular 4-6 week requirement cycles, you are going to hit a wall.
Maybe not in the current cycle. Or the next. But eventually - especially with the lack of resources on hand.
Big companies can get away with this because they have entire teams dedicated to writing and analyzing those requirements and the process with which they are derived and developed.
However, in a team of 15-30 people, you should be more worried about getting priorities full working…not written down to the point you have to use a dolly to carry those documents between your desk and the desk of your project manager.
Silos Between Groups
The road to hell is paved with good intentions. That’s how I’d describe silos.
There is a weird start-up dichotomy, which is folks need to make-up for the lack of certain roles that aren’t in a budget, but they also must do their job. It’s so nice and sugary sweet to think that everyone is a generalist that can step-up and help rally the troops wherever they are needed.
These people are very few and far between - and really have their limits.
But, on the flip side of this is “everyone must do their job.” There is a misconception that stepping out of that boundary can cause a lot of tension due to toe-stepping.
It really lies somewhere in between.
Things cannot be lobbed from one group to the other without communication. That’s a really, really bad sign. The thing to watch for to determine if silos are in fact forming is communication and involvement.
You should be talking to everyone regularly, and they should be talking to you. That’s not to say you should be having all-hands meetings every week or having everyone reading each other’s e-mail.
Let’s not get crazy.
But, that is to say in order to work together you have to have trust and the right steps must be taken in order to build that relationship so it’s down right effective. Silos are nasty buggers that can also lead to culture shifts (described below) and one of my all-time favorites (not!)…turf wars.
Culture Shifts
In some cases, people can cause culture shifts. They don’t happen overnight, but they do happen - and when they do (and they are negative) they are extremely taxing on the business and very difficult to repair.
While the CEO should be watching for these regularly, they don’t always have the option of seeing every little thing in the field, so it’s great to recognize when they do rear-up to have a chat with those that need to have them called out.
Doing so, and learning to spot these suckers early, can ease a lot of stress and tension and severely dropped morale later down the road.
Will to Act
Everyone must be willing to take action to get things done. Too often people can become paralyzed by the notion that things are really hard, eat up their time, and cause them to be frustrated.
Now, of course people spending 24 hours a day at the office is bad. But the odd time, there are required pushes where people will work overtime in a start-up — because that’s how things go.
Everything in a smaller company can tend to be hyper-amplified in many different ways, making them appear really out of reach or frustrating. Some times, the only way to move past this is to a) recognize there is a problem b) determine the solution and c) execute.
It’s crucial that things don’t stagnate or stop moving forward - that’s when there is a serious issue at hand.
What To Do
Learn to spot these bad boys early and often. Learn that you don’t know everything and that your instinct could be off but 9/10 it’s way better to be safe (and have a discussion about this stuff early) than sorry (i.e., trying to explain to your higher-ups why you didn’t call this to their attention sooner).
Maybe your wrong - maybe your crazy. But chances are, if you’ve seen the movie a couple of times before, you have a good enough understanding of these types of things to know when to call a spade a spade and bring it up.
What Are Good Requirements?
What makes a good requirement?
That’s something that is completely open to interpretation. In my humble opinion, a good requirement is one that is clear and direct. It communicates what it is supposed to and then moves on.
No muss, no fuss.
There are many out there that will disagree with me on this. That’s OK - it’s all open to interpretation and what you’ve seen work before, or have tried, have succeeded with, have failed at, etc…
See to me, in the scenarios where development is not run by product (which should be every scenario if you want to do things right) you need to have a good partnership there. If that doesn’t exist, things will go down the tubes pretty quickly. That being said, you don’t have to love each other and hold hands - but something has to be shipped.
Now, to boil this down pretty quickly, I really see there being only two types of requirements:
1. Agile requirements; and
2. Waterfall requirements
These are really polar opposites of one another. You can’t get much different, aside from the fact that you are communicating the same problem you want solved within each - they are both just different ways to communicate them.
The thing I have come to realize is that for agile to work - for it to really work - you need everyone behind it and you need pretty smart developers who are on the ball. The main reason for this is that you want great code to be written, but the time you are saving by not writing long (and I mean looong) requirements documents produces ambiguity, and that must be filled in by the developer as they go.
They must ask questions. They must talk to you (the product wonk). And above all, you must trust each other.
Some developers have serious issues working this way - I get it. I understand it’s not easy. It puts a lot of onus on those that are writing the code, as opposed to the waterfall way….
Now in waterfall, at least in my experience, you are pushing away communication in favor of documentation. Developers want every single piece of a feature mocked-up, written down, and worked out before they even start thinking about the code. I always picture this style of process as taking things and lobbing them over walls. Requirements over a wall to dev, code over a wall to QA, QA over a wall to production, etc, etc…
Especially if your team is small, working this way is not leveraging one of the team’s crucial strengths - it’s size.
A lot of companies work in waterfall, and it does have its place. Specifically in organizations that demand a heavy process workflow through a release - or something that has a ton of formal check points. Two examples here (respectively) could be a bank and a consultancy
If you are going gangbusters trying to get products out the door, the last thing you need are formal check points. The last thing you need are 50-100+ page requirements documents. But that is what happens. This gums up the works for several key reasons.
The main one is, people stop talking. They stop asking questions. They just assume they can blindly follow the documentation - and if it doesn’t turn out right, oh well - wasn’t documented that way, so it’s becomes a bug. People way smarter than me came up with the agile manifesto for a reason. It can and does work.
People are smarter than this and everyone should expect them to be.
Of course developers need things to go on. You can’t expect them to read your mind and they can’t design anything (in most cases). But they are smart. After all, they are computer programmers.
The bottom line is this - no one can tell the future. As features get implemented, they change. Sure you know a lot of things up-front (button goes here, text goes there, save this, etc…) but you are 100% bound to miss things. If your product release process doesn’t account for things being missed down stream, it’s wrong.
Remember one of the key tenets of agile - put things off as long as possible until the last possible moment you can decide to ensure you have the best set of information at hand to make that decision.
Those things don’t happen in closed-door offices with a product manager huddled over his keyboard typing out requirements and acceptance criteria fast and furious. They happen in talking to those coding out those ideas and breathing life in to them.
But, not all teams are cut out for that sort of challenge. And that’s OK too - just make sure your management team knows you are going to need a solid chunk of time (1 1/2-2 months) per release cycle. And make sure you have some spare toner and paper ready for your printer. You’re going to be doing a lot of editing on those requirements docs.
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.
The Importance of QA
I am in the process of hunting for a great senior QA analyst. That being said, I wanted to take some time to talk about how important QA is in the product management process; or at least, how important I view it to be.
In my experience, if you are able to find and bring in the right QA person, that’s really into QA (and not just using it as a stepping stone), they will have a strong / noticeable impact on your product as early as its next release. I’m not kidding. I was lucky enough to work with a very talented QA engineer / analyst while at MusicIP, and his work ethic and results were absolutely perfect for helping us with several key initiatives.
So, what are some of the things that I’ll rely on QA for? I’m glad you asked…
Primarily, you don’t want defects in your product. I view the role of QA to help identify and manage bugs, but also prioritize them and ensure they are getting fixed. This way, I can stay focused on planning the product and trust that when a certain set of users can’t do something they are supposed to, it will get taken care of accordingly.
So, this means setting up your QA team to succeed. And usually, that means metrics and objectives. The key metric I’ll look to that’s directly tied to QA is product quality. Essentially, this is an amalgamation of high severity defects throughout the product (1s, 2s, and 3s usually). A great QA person will derive these priority values by assigning visibility and class rankings to them. For example, how likely is it a user will encounter a specific defect? And, if they do encounter it, what is the likelihood of it completely hindering their product experience?
You need to have these checks in place in order to ensure what you are shipping (especially as it grows and becomes more and more complex) is of the highest possible quality.
Now, the other key aspect I look for in QA is sanity checking my requirements and making sure their associated test plan runs the gamut. I may state that a user “must be able to create an account” and that “the username and password fields are required,” but the QA analyst will take this one step further and actually determine all of the permutations (that either may or may not be documented in the requirements) development must cover.
In this example specifically, maybe the e-mail address the user enters is malformed. Maybe their password doesn’t match to the 6-character standard. When you are working on releasing code quickly, especially in an agile system, this type of coverage becomes crucial. I need that constant stream of discussion and feedback.
Essentially, I’m looking for trust - not only from the product team, but the QA team (regardless of wether they sit in product or engineering), the development team, the marketing team, etc… I want to develop the trust that the QA team will catch critical user flaws (hopefully) before requirements even get to development for implementation so we can work out the kinks and ensure they are as clear as possible.
Beyond this, QA can really help development too — with structuring automated test suites, tracking their results per build and really grinding out the processes to ensure maximum build effectiveness (especially when using continuous integration tools) and insist the quality is really high and stays there. They may also be able to help when running core A/B tests on a site to help determine if user’s are encountering critical flaws in one implementation and/or another and what the outcomes are of possible change.
Remember, the “Q” in the abbreviation stands for quality. That’s their job. It’s not to administer servers or to be an authority for developers. However, it’s one of the most critical jobs in an organization - especially one that is just building / starting out. If the product you are releasing is poor quality, chances are it’s going to get very far.
Bring in an experienced QA person early and really maximize their value as much as possible. You won’t regret it, and your users will thank you for it.
