Overarching Ties
For those of you that are in multi-product environments, chances are you are working with more than 1 product manager. I want to get some thoughts down about effective methods to do this.
Now, to me, the most effective organizational structure is to have a Director of Product Management who then has a team of PM’s reporting to him or her. There may be some other groups that report in as well, but that’s for a different post.
There could be a scenario where you have a director, a VP above them, and disparate PM’s across the org. Now, as a PM you need to recognize that you must a) build indirect power and b) know how and when to use it. So, even if your are in a situation where you are a director with 1 associate PM and two other team members reporting to you, you still have responsibility to execute on the role of director.
I’ll leave out VP-level stuff for now, because it’s out of scope to get into things like managing a PM budget and stuff like that. Again, this isn’t hard folks. It’s easy if you think about it enough, employ common sense, and have a good team supporting one another in the company. But again, outside of scope for now.
So, as a director, you will have a team. PM’s should be good and focused on making sure they can be effective managers (because that’s just effective management, which has nothing to do with PM skills), and still be good PM’s. Directors also have the added layer of determining synergies across an entire line, or multiple lines, of products.
The key here, like all effective management, is delegation. You don’t need to get involved in gathering market data for the products the PM’s reporting to you are working with. That’s one example that would be bad. You REALLY don’t want to start telling them how to construct their roadmap. This is especially true if you have older, more experience PM’s working for you. I’m super touchy about my roadmap, and trust a certain group of people to provide input. This is because I OWN it. It’s mine. I’m responsible. I need to track it, modify it based on my hard-earned research, and flag higher-ups down when I know we’re not going to make a release or we’re going to slip a date.
You are asking for trouble if you start meddling, and telling other PM’s how to manage their product. Funny though, eh? This is just effective delegation. The task is, “manage this product” / “lay out a plan to manage this product, then execute.” Sure, you will want to review key deliverables and understand them — but that’s FAR different from saying, “here’s how to create a roadmap — do 1, 2, 3.”
One of the *key* director-ship responsibilities is identifying cross-product relationships. How can other product teams help other product teams? How can 1 product be more successful in the market if it were to work with another? As a PM director, you are in the spot to recognize this stuff, because it’s all feeding into you. If you are drowning in work, you haven’t delegated OR you need to hire additional help. If you are in a startup, there’s probably no budget to do that, so keep it kicked into high gear.
This all ties into milestone reporting, which I talked about in some other posts a while back. Sit down with your PM’s and identify milestones, and manage to those. You don’t need to be Jack Welch, or have 30 years in business to know how to do that. Communicate, walk over to their desks, discuss things, listen, hold team meetings, leverage one-on-one’s, etc… it’s just effective management. And those concepts take time to refine, but not understand or execute.
Also, you are at the higher-leve of air traffic control. You need to help your team leverage others in the organization if they have to. Typically, PM’s will make do themselves just fine. They should be personable, knowledgeable, and driven enough to get in there and get their hands dirty. However, monitor and ensure that if they need help communicating with Sales, get it to them. AND, if Sales isn’t getting the communication they require about a product, make sure they get it. Air. Traffic. Control.
Most of all, live it, love it, breathe it. I’m up late working and thinking about this stuff because of three fundamental things: a) I love product management. It’s a true passion. b) I love the products I work with. c) I have zero patience to restrain my ambition. I’m getting better at understanding it, but that doesn’t mean it’s hindered me from going 1,000 miles a minute.
I don’t know if any of this made sense — much if it I just wanted to write through as it helps me learn. Maybe Jeff will create a post on “If you want to be a BAD director of product mgmt, do all of the product management for your team of product managers,” or something. One thing’s for sure — it would be way more helpful than my ramblings here, I’m sure.
Model to Execution and Back
I’ve been working so hard over the last 6 months to get a process and model in place for how things are working, and now that it is, it’s all a matter of working stuff thru and executing. Then you really find out what the weaknesses are in what you’ve devised.
Change / modification is necessary, and maybe you stuff to flesh out a plan for where you see you’ll need help, resource-wise, within the next 6-8 months or so.
One of the first places I started was my product model. Yes, I keep linking back to that damn post, but it really created a strong foundation, and is helping us drive toward common goals and explain things much more clearly.
Essentially, that model was devised as a result of doing a portfolio analysis. I needed something quick that helped me, and I was hoping everyone, understand the technology and the products.
From there, I was able to move a little bit of that communication forward. We continue to work hard on building out good documentation - product guides communicating business value, user manuals (where applicable) for detailed instruction, API references for developers, release notes, and even training are all things we’re building on.
The next logical step is to a) get a roadmap in place and b) start the scheduling if that’s not already happening. Both of these may take some time, especially if they are first-time things in the company. It’s tricky to get all of the knowledge extracted and down on paper from all the different people that hold it.
Part of that roadmapping process was creating some formalized product plans - product objectives that were tied to company objectives, formalized pricing, and marketing plans. I started really driving the “cross-functional” aspect (yeah, with 20 people — kinda funny) more here because this is when folks have to really start getting involved with their part.
Marketing had all of their plans, but they needed to be in tune with the roadmap / current product analysis in order to fine tune them. Then, they can go into the product plan. Objectives all have metrics associated, which finance needs to be aware of - especially if you want to do product P & L’s. Fine for the big boyz, but for me, a little too much at this point. I like my spreadsheets.
There are bound to be breadcrumbs. However, my philosophy is to recognize them, but not force them. You’re probably working on a million other things already that are just (if not more) important than the crumbs. If you have a loving / caring founder, they are aware of them too. If they are important, you will hear about them more than once.
I hope this doesn’t sound crazy, because I’ve been quite aware the entire time I’ve been doing this what the next steps will be. However, there are a few things that have surprised me because I haven’t done this 8-20 times before.
1) False starts. You know you need to get something done, but my mis-interpret the correct time to do them. That’s OK — just back off slightly until it’s the right time. If you try to force roadmaps where they haven’t been forced before they will suck.
2) You know what needs to be done. Product Management is billed as strategic, but there are a lot of details to manage. Especially when you get into dev scheduling and so on. Work with people, and don’t let detail management disguise itself as YOU feeling like you need control over everything. Like forcing roadmaps or scheduling process, it will cause things to dismantle. And you’ll probably be out of a job.
So, next steps? Well, now that my foundation / framework has been put in place over the last few months the fun can start. Not that this hasn’t been fun.
Communication, especially in a startup, is SO important. I can’t stress that enough, and yes, it’s a very valuable lesson I had to learn. You are in the driver’s seat here as PM’s folks. If you are concerned about communicating detailed roadmap and release dates to Sales, you must get over this. Make sure your standardized contracts are in place to catch dates / slides that may have a tendency to slip in there.
Everyone is going to make mistakes - including you. Just learn, fix them, and keep charging ahead.
In addition to communication, I have found pricing to be challenging, especially in a nascent market. You don’t really have a baseline. BUT, you need to get this done and not let it scare you. Monitoring (and the metrics / objectives set during product planning) will guide you to market dominance. Just stay focused and don’t wildly vary all of the place. Keep referring back to your vision.
Sales. As a PM, you have to get on the phone and do some sales. Whether these are leads from trade shows you’ve gone to or whatever, but just start talking to people in the market. This is the next big thing for me - gathering that data to make sure a) our roadmap hunches are correct and b) our pricing is picking up.
Oh, and of course, getting product out the door. For some reason, I know all the steps we have to go through, and with my team I’m working on crystallizing those now. Just because I didn’t take the Blackberry or MacBook Pro to market doesn’t mean I don’t know how to do this - and the same goes for everyone.
For example, on Jan 5 we shipped a rev to one of our key products. This past week we shipped a new utility that works with two of our products to make our client’s interaction time with our stuff more streamlined. Next week, we are shipping another product rev, and will do so the week after that with something different.
“Shipping” involves a lot of moving parts. If you are the first PM in a team that hasn’t had a PM before, you are going to face some interesting challenges. But don’t let that get in the way of you understanding the components that need to work in order to get an effective product (or even something small as a utility) out the door. After all, you own the roadmap and have put the marks in place that determine success.
Make sure you get the stuff out there you are responsible for and communicate.
All you senior PM’s and PM directors - an additional layer is added to your workload of recognizing opps in creating ties across all of your products. Heh. This is also something next on my list, but I know takes some time - but, now the foundation is place (see - way before in this post) it’s SO much easier to bring multiple PM’s together.
And now….time for lunch.
On the Way to More Shows
One of the things I have to get better at is acting as the proxy between the company and the market. To do that, of course, I need to immerse myself in the market we are in.
This involves customer visits, phone calls, trade shows, sales calls, prospect interviews, and more. I know all the things that need to be done, but finding inventive ways to bring it all together is where I’m at today.
Maybe I need to stop worrying about the process, and just get the data and dump in a spreadsheet or something. That’s what I’m going to do at the next trade show I’m headed to at the end of the month. We have some prospect meetings setup, and I’ll be wondering about asking people things.
I always love walking the floor at shows, introducing myself to everyone and listening to them talk about what they do. I love to hear that passion people have for their company / work / products. I can then more easily take that info and either a) decide we have a solution for them b) they are re-iterating what we have on our product roadmap or c) we should be looking for ways to do what they are describing.
For me, it’s all about the roadmap & tying data gathered back to that roadmap.
Once I get more of it, and believe me, things are getting pretty interesting in space I’m in, I’ll be sure to pass on how I’m evaluating and connecting to roadmap.
On, and I’ve already decided that my first MRD will be bullet points. 2 pages, tops. Scott, I apologize up front =)
Air Traffic Control
I’m really lucky to have some really great and smart people around me all the time. I have been since I got into the work force.
One lesson I learned this week? Effective management is about air traffic control.
Getting information in, devising what needs to be done, delegating, and then following-up. I’m not starting to realize this what all those books mean that effective managing is all about delegating. I just never thought about it this way.
This kinda ties back to my post a long while back about status reports & checking in using milestones as a gauge. Once some of the folks on my team are comfortable with the direction we are headed in, I want them to be able to set their own goals within the vision of what we’re doing.
Then, any inbound requests to me related to what’s going on are simply routed their way to be handled properly, and I can then provide any necessary communication or guidance on how it can be handled (if necessary or requested). I’d hate to turn into someone that was always saying, “this needs to be done, so go through steps 1, 2, 3″. I just want to say, “this needs to be done. I don’t care how you do it, I just care it gets completed and at a high quality. Ask me for help, and I’ll check in with you for a status at point X”.
It’s all very interesting. I love learning this stuff and then incorporating it into my behavior and how I work. It’s all a learning experience, and a damn good one.
Ask for Help
One of my challenges as I mature and grow-up (in the work sense) is knowing when to ask for help.
It’s really easy to want to take everything on yourself, but you will inevitably end-up bottlenecking something, and that slows down the machine / momentum. You don’t want to be the cause of that, although for those of us that eat and breathe ambition, that’s tough.
The last couple of weeks for me have been really fast-paced. But I’m really learning so much - especially about a) executing key product management tasks and b) management. I got caught off-guard when I went through a deliverable review this week as part of things my team is working on.
It was the cause of it not being done as completely as it could have been, and that pissed me off.
But, I now know (yes, from hard lessons learned) that I can’t let that stuff eat me up as it has in the past. That paralyzes you (me especially), and as such, work quality degrades.
So this time, I’m getting off my ass and actually letting it inspire me to do better. Management can be tricky; while the concepts are easy, the devil lives in the details. I’m not, and never plan to be, a passive manager. I love being involved and communication vision, and things like that. I just need to get better at paying attention to detail.
Ahhh, thanks for listening. Heh. As I was writing, I just connected the dots there in my head; wow, funny how that works.
One thing I have noticed before, and noticed it again today, is that throughout my time in the workplace, I advance by jumping knowledge / experience levels. And, it’s always a clear step for me. Not “title” or “salary” or anything like that, but having gone through certain things a couple of times and picking up on details.
I just made a level jump this afternoon, and thanks for hearing me out.
