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.
Where Product Mgmt Sits
Product management has to report to the CEO. This is really not something that is up for debate.
There is a lot of data suggesting this is not presently the case for many organizations, especially in tech - and that has to change.
In order to be successful, product managers require a lot of input and clout over most of the cross-functional teams within an organization. Without the support of the CEO, it may be nearly impossible for the PM to strike a balance between marketing, sales, dev, etc… If the PM reports to marketing, that leader (vp / director marketing) will have a tendency to ensure all marketing priorities are put first. If the PM reports to development, same drill - what the dev manager (CTO / vp, eng or whatever) feels is important is what will be worked on.
Don’t even get me started on the prospect of product reporting in to sales.
Product management has to be able to move laterally (and actually make decisions) in order to ensure the best interest of the users / customers / market are at heart. If this can’t be done, the product will veer in one direction or another; and that direction may not have what’s best for the market as a clear intention.
I have had conversations with several colleagues in the space (Jeff Lash, Saeed Kahn, Scott Sehlhorst, etc…) regarding product management not being a “standard” role within an organization. In fact, I’d love to pose the question to VCs (say, Fred Wilson, Rick Segal, and Brad Feld). When you invest in an organization, how important is having a product manager on the management team?
Do you explicitly look for a director / vp of product management just as you would a vp, sales or vp, engineering? Maybe even a vp, marketing? Is hiring one a key action item for any CEO you are trusting with your investment? If not, how come?
A long while back I spoke with a recruiting manager for a very large social networking organization in the Bay area. He informed me that they were “incubating” product management in development, and the CEO “may decide” at a later time product should have a seat at “the executive table.”
Wow. That’s a whole lot of words telling me potentially a couple of things: 1) development is driving all product, which tends to be a common setup. And it’s not usually the best thing in the world. But then again, I’m heavily biased. 2) the CEO thinks they are doing a fine job and don’t want anyone challenging their decisions, execution, etc….
In my opinion, you need product management in the organization, and a PM lead that reports to the CEO and has management-level “authority” (whatever that means to you). Otherwise, the product has a strong chance of becoming heavily weighted or biased towards the group that’s charged with running it - unless there is constant intervention by the CEO.
Personally, I think a start to this is to get product management to be an actual subject / role / element taught to business students in MBA programs. Finance is. Marketing is. Sales, strategy, “organizational behavior,” etc…. Why not product mgmt?
Maybe I’m just too heavily rooted in software - it could be the role isn’t all I’m cracking it up to be in other industries.
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.
Why Product Management Is Easy
I track the term ‘product management’ on Twitter. You can see the results of that search term by checking out a handy tool called Tweet Scan. Essentially, whenever someone mentions the words “Product” and “Management” in a tweet, I get alerted on my cell phone by way of SMS.
I’m a nerd, but I find it interesting. And, yes - this turned in to a hella long post.
Recently, and you should see this if you look at the search results, I’ve noticed a couple of folks talk about how hard a job product management is. I wanted to make some points here about this, and hopefully put to rest reservations folks may be having about exploring the possibility of getting into the job, or maybe even continuing doing the job if they are already in the thick of it.
My take is: it’s not hard.
Now, I’m not a product manager in a big, massive company. I never have been, and if I were a betting man, I’d say I never will be. That being said, I do in fact recognize that there are differences in how product management is done at say, Microsoft, and how I’ve structured it in the past. This is just due to the nature of the size of the organization where the job is sitting.
So, keep that in mind. My take on things is really related back to 20-50 (maybe 100 or less) person organizations. Anything upwards of 10,000 or 20,000 person companies really boggles my mind. So, hopefully that’s clear.
I do in fact recall when I was first put into the role. It was exciting, but at the same time, really ridiculous. Not for any other reason than, I wasn’t working for a more senior product manager to kinda guide me a long and instruct me on what to do - I was in there on my own learning as I went. It turns out, this is ideal for me, but I recognize it’s certainly not everyone’s cup of tea.
This leads me to admission number 1: The job is damn near impossible when you first start. Actually, scratch that — it’s damn near impossible when you get 3-4 months in. This is because, at least from my experience, it takes people about that length of time to really wrap their heads around what it is they are supposed to be doing. And I believe this is where most would sink and maybe start believing, “this job is WAY too hard for me, or anyone, to really do.”
And that’s 100% true. The way the job can be defined, it is impossible for someone to excel at. If you think about needing to be “proficient in Sales, Marketing (specifically, messaging and positioning), have a strong technical knowledge, excellent project management skills, well-versed in strategic alliances, and have a good foundation in finance.” Yeah. That’s a little tricky.
Let me take some of the surprise out of this description - there is no one that is “highly proficient” or “expert” in all of these things. They just don’t exist. You will either get a “tech” person, or a “sales” guy / gal, a “marketer” or a “project nerd.” But all of those wrapped into a single individual? Yeah. Not so much.
Now, this is where people may start to get down on things. How could you possibly do a job where all of those things are important? Some may say, “this is exactly what I think it’s HARD.” OK, well hold on - I’m getting to why it’s not.
Yes. those things are important. However, in a position like this, delegating is absolutely critical. That’s why you will usually see the line about “leading without authority” associated to many product management job descriptions. Why? Well, I’ll use myself as an example.
1. Am I a marketing genius? Hellz no.
2. Am I a great software programmer? Ummm, far from it. I may know a little LISP and SQL here and there.
3. Am I great with numbers? If you asked my grade 11 accounting teacher, she would say, “HAHA. No.”
And so on.
But here’s the key - if you understand *conceptually* how these things work, and maybe more importantly, how they work together, you are doing the right thing. No one person can build a great organization - it takes teams of people to do that. So, let’s re-visit those questions above with some modifications to them.
1. Do I understand marketing and have great marketing people to work with? Yes.
2. Can I give flexible requirements and wireframes to the outstanding developers and watch them develop wicked code? Yes.
3. Can I ask the finance people I work with to help me track project budgets to make sure I don’t go wildly out of control? Yes.
At the end of the day, so long as I understand the critical nature of cohesive positioning and building brand equity and help play air traffic controller to make sure marketing can do it’s thing, I’ve won. I can completely let go and push. IE, “I can give you feedback and my thoughts on positioning this product, but I need you to write the words and deliver something cohesive.” If they don’t, that’s another issue entirely. But I think you get the idea.
OK, so that’s a big long “admission # 1″ type thing. Once you cross that functional expertise hump, admission number 2 is this: The answers are right in front of you. Sure your opinion will factor a lot into the initial product release / development / design - but use those around you to vet ideas and build some momentum (no “i” in “team,” etc…). Someone actually has to DO things, but gather feedback (at least internally if you don’t have users yet, and then put something out in to the World.
Guess what? You are going to get a lot of stuff wrong. But it’s not about right and wrong. It’s about common sense and building cohesive products. The answers are always there - you just have to know where to look and how to ask.
So, is product management hard? No. The trick is not being the best marketer, accountant, UI designer, developer, Sales person all rolled in to one. The trick is to make sure that features get built, marketing communicates them, support can answer questions, and Sales can sell.
All the job is is connecting dots and knowing where to look for the data you need to make decisions. Don’t get overwhelmed by all the noise.
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.
