Business First, Solution Second
Features are exciting. I know this, because dreaming them up is always a favorite activity of mine. But isn’t there something that has to come before you sit down and come up with how a product is going to work?
Yes - the reason for the product existing in the first place.
Look at the business of the product first. I’ve made the mistake of doing it the other way ’round, and it always causes problems and convolutes the way in which the product is structured.
If there isn’t a clear reason for why it exists, and the direction it’s moving, it will be very easy to veer off-course and come up with features that don’t really mean anything. Dev time can be better spent on features that will actually satisfy the audience.
In my roadmaps, I’ll have a bucket called, “TBD / DEFINED BY MARKET”. I put this right next to my standard quarterly groupings / buckets. This is where I will stick a whole bunch of thoughts and feature ideas (that usually make sense), because they don’t yet fit into priorities. They are left there for discussion.
Only when the features are at hand should the requirements and specifications be decided. It is then that the time is well spent. They are in everyone’s sights, and can be focused on. If they are drawn-up too far in advance, and too much detail is spent on them, they will only end-up changing anyways.
I’m currently of the mind that it’s better to talk to the developer first-hand and see what they think. If the team is built right, this shouldn’t be a problem. I know — size and all that come in to play, and I’ve had to write huge requirements docs in the past. But, not that I don’t have to where I am now, I’ll have to be dragged kicking & screaming back and away from my napkins.
PM Traits
This is a fantastic article, and very well positioned. Recommended reading out there for not only PM’s, but those working / managing PM’s.
For me, the one that hit closest to home was point # 1. I still find it difficult to serve as this “hub”, but am working really hard on it to get my crap together.
I think it’s the personality switching, and how fast you have to turn certain filters / things “on” and others “off” based on who you are dealing with at any given time.
I recently had a conversation about this with a good friend. His advice? “It’s your job.” True enough, true enough.
Thanks for the post, Michael!
My Upcoming Webinar
I was just confirmed for the Product Management View webinar series on April 25, 2007. I’ll be doing a presentation on Startup Product Management — much of it will be based on my blog posts, and offer additional insights based on what I’m currently working on, as well as past experiences.
I’ll post more detail when I have it — should be a ton of fun!
The Product Team
I’ve found that there is a distinct need to have a product team, and to work with them regularly. This is different from the actual product management team, and this post goes into some detail regarding building product teams and why they are crucial.
For me, I can’t work in a vacuum, and I don’t ever recommend that people try. It sucks. I’ve worked in scenarios where feedback is limited (both good and bad), and that lack of direct communication can really end-up leading someone down the wrong path if they don’t have enough experience.
This is why I like to make sure there is a strong tie / bond between a few key cross-functional leaders in a company, since those are the folks, along with the PM, that are driving product decisions. A product mgr can’t make all the choices, all the time, by him or herself. If you have a PM working for you that is trying to do that, I suggest you evaluate, and quick.
You want conversation and constructive discussion across the entire board. For me, I like to work with folks on a “product team” that are a) super-into what they are doing b) have bought into the vision whole-heartedly c) believe in me and what product mgmt is all about and d) have more influence in the company than myself.
That last one is a funny one because it’s truly not a matter of brown nosing, but a matter of realizing that in my scenario, even though I’m helping drive a lot of key things forward and sometimes my ego likes to think that I am a Director or operating at a VP level, the truth of the matter is, I’m just not. I’m not part of Senior Management, and probably won’t be in this job, and probably my next job.
So, in a company that’s as small as I’m at now, it’s key for me to have folks that really understand what I’m trying to do as a product geek, and support decisions I’m making so they can go to bat for the products themselves (not for me — I don’t care about that) and make sure other Senior Mgr’s understand why certain things are being pushed the way they are.
Plus, at the end of the day, I like have that team of people to turn to for support. When I’m not sure of something, it’s incredible to be able to get clear, concise, and above all else — constructive, feedback from them. It’s not, “you’re too young, which means you’re stupid. I’m going to school you now.” They recognize how critical the products are the companies success, and why certain things are the way they are.
And for what it’s worth, the trust you are doing your job, and you trust they are doing yours. And you come together to build out good recommendations to discuss with your CEO’s and your VC’s. And then you pray THEY recognize that the people involved in making product choices understand the task at hand, and are doing their jobs. Then it all starts to flow and work together.
So, thanks goes out to the product team I am working with now — you guys know who you are. Just know that you make my job a helluva lot easier, and I wanted to try and communicate that to other PM’s that could be reading this so they can start thinking about how a structure like this one can help them.
Talk, Talk, Talk
Why is it so important to talk about your product all the time? Because how else are you going to get to know it better than anyone else?
You have to talk about your product(s) constantly, with as many people as possible, and try to keep the conversation on an applicable path, and the things you learn will be immense.
For example, working with prospects will divulge details such as: a) things they are looking the product to do b) how they are feeling about your pricing and if you really trust them c) how they react to your roadmap and d) how they really feel about other options they are evaluating in the market.
This doesn’t only go for prospects of course, but your actual customers. I like to treat those customers that I am able to build a relationship as design partners of sorts. Bounce ideas off them, see how things you have on the roadmap would impact their business. If they are really into what you are doing, and you have a strong relationship there, they aren’t going to start holding you to promises and acting like an ass.
Once of the things that I like to have worked out with Marketing is gathering this type of market data. In order to products to be successful, you have to have more than just yourself working for the customer, and the market at large. If they aren’t, you are going to miss key things, and a PM can’t be in more than 1 place at a time.
Everyone needs to know what to look for, and I recommend wrapping this up into product training, along with other key fundamentals (how your release cycle works and why, product plans, communications, etc…).
Remember — to a PM, calling on customers and talking to prospects about things they are looking for and feeling my seem like a natural thing to do. But for someone that’s not really immersed in that concept / culture / notion may not think of it. To them, certain things like this may seem inconsequential, when it fact, they can make or break a product — and ultimately, a company.
