First Days On the Job
So, you just become a P.M. Congrats! Now, what does that mean to you?
Well, if you’ve never been a P.M. before, hopefully your manager knows what it’s all about, or is a P.M. in the company themselves. If they don’t, you’re going to have to work doubly hard to make sure they know - and they are clear on what kinda value you deliver.
So, what are the steps? Well, first stop freaking out. It may seem like you have about a million things to do, but life just ain’t that bad. Seriously. Take some deep breathes and grab a coffee with your manager and have him or her step you through all that’s going on. It’s never as daunting as it seems.
The first realization of being a P.M. is, your time management has to be very good. You have to know when to say “yes” and, more importantly, when to say “no” to something. For example, if you have an active sales force at your organization (and hopefully you do), you can very easily slip into the role of demo boy / girl. Know your boundaries, and know your limits.
If you find you are having a hard time staying out of all those sales meetings, seek guidance on how to handle that, or just getting some help.
Are you still remembering to breathe? OK, good. Moving on…
Let’s look at a couple of items that a new P.M. can work through to get their bearings. Steve Johnson posted a great P.M. triage article a while back, but from my point of view, it’s a lot simpler than this. You’ll see some overlap here, because he’s Steve Johnson, and he’s forgotten more about shipping products than I’ll ever know.
Step 1. What is your product(s)?
The first step is to really define the products your managing. Maybe you have a jump-start on this process, or maybe not. It isn’t difficult, and the Party of Four model works to get yourself and everyone else on the same page with what you are thinking. It’s simple and to the point, and the content can continue to be iterated on once you have the first pass.
If you have multiple products in your assigned portfolio, prioritize their importance with our manager to ensure you are giving TLC to the right ones. Remember, there are folks at the company more immersed in the technology and the products at this point than you - and that’s a plus and minus. Definitely leverage your unique, fresh perspective to question why things are they “way they are.”
Step 2. Understand Corporate
The wastepaper basket should not be a special filing cabinet for things from corporate. (Sorry, big fan of the Office). Make sure you clearly understand the high-level before proceeding into the trenches. If you don’t know the high-level strategy / reasons why your product(s) exists, it’s going to be hard to make sure they are at the top of their game.
Step 3. Understand the Tech - but Don’t be Silly
In tech, as a P.M., if you can’t actively and effectively converse with development, you are in trouble. You don’t need to know HOW “code A is pre-loaded into the buffer at memory allocation Y for 5.3 nanoseconds….” but you must understand the WHY. If you can’t articulate how the technology behind the products works, you’re not going to gain much credibility with development, making it hard for them to take you seriously when you start handing them requirements for the next version of your product.
Remember: you are the proxy to the market. If you aren’t running engineering, you aren’t running engineering - leave that up to the people who’s job it is to care about the “how.”
Step 4. Understand the Roadmap and Market Research
You need to understand what, if any, roadmap exists for your products. In addition, what data was used and how / who was it gathered from to make those roadmap decisions? Once you can get immersed in your product’s market segments, the problem that’s being solved (see point 1), and what data is being used / gathered now to serve them, the more of a chance you will have to take that management to the next level.
Step 5. Look for the Wins
To me, one of the primary functions of a tech P.M. is to actually ship product. Whether it’s a v1.0, a major rev, a minor rev, etc…. you need to get that under your belt if you haven’t. It will be stressful, but if you’re prepared and have good folks around you, it should be pretty smooth sailing.
At the end of the day, there’s plenty of things you can and can’t do - but most of it is common sense. If you are a new P.M., and are stepping into an established P.M. organization, expect some hard work. Your manager will want you (hopefully!) to succeed with flying colours, so make mistakes and ask. You wouldn’t be in the position if they didn’t think you will blow the doors off of it.
You’re there to ship some product - so, figure out what you’re shipping, and get it out in the market. If it breaks down and doesn’t do what it should, plan your iteration accordingly and ship again.
Behind Closed Doors
I just finished reading perhaps the most honest and streamlined book on management I’ve ever read. Behind Closed Doors: Secrets of Great Management is amazing.
It works through the story of a Director of Software starting his new position at a new company and all of the challenges he faces with while starting to work with his team.
Some great principles are covered, and the book provides examples and tools for communication and working through the day-to-day challenges that management presents.
While it’s focused on a high-tech, the fundamentals provided can be applied to any industry. While reading, I kept going back to what I’ve learned from Manager Tools for reference, and reflecting what the authors of the book were saying to what Mike and Mark discuss on their outstanding podcasts.
While a lot of the content was familiar ground, the book offers a little bit more of a relaxed feel to giving feedback and executing one-on-ones that I preferred. The Manager Tools is very, very good - but I’ve always found it to be a little bit more formal and targeted towards large-scale organizations; not start-ups, which is the world I’m from.
In any event, I encourage everyone to buy the book and subscribe to the Manager Tools podcasts. After (even 2 weeks) you’ll have a better foundation for management.
Communication with Multiple Products
There’s a major trick to having a product portfolio that spans both business and consumer and includes, not only several major products, but also a lot of little utilities that go into those products being successful.
One of the hardest parts about this that I’ve found thus far? Communication.
How much is enough? How much is too little? When you’re working within a smaller environment, what’s overkill?
All these questions are tough ones to answer, especially when you are just building out the portfolio. There are so many tools out there that can be leveraged for effective communication, but what’s going to ensure that the important messages get through?
A lot of it lies with the sender / communicator (you).
Garbage in, garbage out, right? If you find yourself sending several product updates in a day, chances are, they aren’t really that meaningful. I’ve tried out several tools over the years, and am finally starting to think I’ve hit on good combination. Chances are, that will change again in another few months.
I tried Pownce out during the testing cycles for a v1.0 to get it out the door. It worked OK, but then some folks on PC’s at the office had the desktop client just crap out on them. Gross.
I’ve been using Twitter to announce releases and link to release notes. That’s going pretty well so far - especially since there’s not a ton of volume when it comes to releases.
I communicate with management internally using e-mail. However, that’s going to have to change soon, I think. Having a weekly product meeting is probably more effectively, however, more meetings is definitely not the answer. Trying to make sure everyone has the information they need at any given time is more conducive to an effective environment than meetings; that is, if I’ve learned anything by reading Peter Drucker.
I’ve been demo’ing Version One in recent weeks, and am very close to buying out a license. It’s probably the best PM software I’ve used thus far, and I have tried several products. We’ll see how things go. For a tool like this to be successful (and like any internal management tool) people need to use it regularly.
Would this circumvent weekly meetings? Chances are, probably not. But, maybe. Shouldn’t everyone be able to login, or get an e-mail they can read as their schedule permits, with key data regarding product releases / activities going on for that week? Maybe a cross-functional product meeting stems from having a weekly staff meeting with your folks.
I think that might work more effectively. And, I’m realizing now that I’m doing this stream-of-conciouness. Sorry.
So, to sum up, here’s how I’ll be managing product communications more effectively over the next couple of months, and we’ll see how it goes:
- Twitter for release notifications
- VersionOne for requirements / planning management
- Weekly status emails with a report exported from VersionOne
- Weekly staff meeting that doubles as a “product meeting”
- Irregular training sessions as the need arises
As I bring some more product manager’s in to the mix at the company, we’ll see how this progresses. I definitely don’t want to do things “just because” other people have done them other places. With this stuff, you really need to find what works for your team at this specific company. It might be the same, but chances are, it’s not.
Use what you know / have done in the past as a baseline, but not the rule. I’ll be sure to post back to record details on how this goes and where it sucks and where it works.
Building the Product Team
I’m currently on the process of laying the foundation for the product management team. Of course, big titles and hiring 200 people at once is not in my line of sight. However, I wanted to write some notes on how I feel you can build things effectively, while maintaining something that’s always important to an organization: subject matter experts.
While PM’s cover a wide breadth of things in the organization, they are not the be all and end all. Ever. They do interact with Sales, Marketing, Finance, Legal, etc…. but it should be in a product centric way, at least in my opinion.
I don’t really agree with the Product Management triad for building a team effectively. Especially in multi-product portfolios. I could see it working well for 1-3 product companies, but not when you have 8-11 products you’re managing. It just puts too much on an individuals plate.
I’m proceeding down a path that will break product responsibility up in to management chunks, especially since our products are not all overly complex with a ton of functionality. So, for example, if you have 3 major product groups, the first step (at least for me) is to hire in a PM that compliments those three areas:
- Product Manager, Group 1
- Product Manager, Group 2
- Product Manager, Group 3
I’m also a big fan of having a group of matrix’d Product Analysts / Associate Product Managers. The PM’s for each product then share those PA’s to write requirements for specific features, help with competitive analysis, market research, etc… The PA’s than get the benefit of working with several PM’s and seeing how they do things. In addition, they exposed to the entire product line - they become very valuable for helping Sales, Marketing, going to trade shows, training customers, etc….
In addition to the product management team, one thing I have discovered is that Quality Assurance really does serve in a front-line, cross-functional role. Having that group under product management really helps out. It provides them with a venue for extracting requirements from users or during a release cycle for continuous product improvements. Support / Client Services works in the same way.
So, you have product managers owning each major group as a first step, and matrix’d QA and product analysts as a second step. Of course, you need to have the product leader overseeing the entire group. This would be referred to as the Director or Product Strategy in the pragmatic triad, or Director / VP of Product Management.
This organizational foundation opens things up for some solid growth. You can then place Senior PM’s in the group, and have 1:1 relationships with PM’s running individual products as they grow and mature. You continue to build the product analyst team, and developing them so you can hire / promote from within. It’s inevitably easier, and the team starts to foster growth and folks who want to excel in order to get promoted into open PM slots.
There are probably lots of folks that would disagree with this structure, but it’s rigidly flexible. So long as the product leader has a framework in place to manage products, it offers the PM’s that own groups / individual products to manage them in any way they see fit, within the boundaries of continuing to provide development and other functional groups materials they expect to get in order to work with effectively.
Some Agile Development Commentary
I’ve written several posts in the past regarding agile development and how we’re leveraging some of it’s benefits internally at the present time. There is a solid post up at Tyner Blain, in which Scott provides some good feedback on a post written by fellow blogger Mishkin Berteig.
There’s a story a friend of mine (who works within a very large organization as a project manager) shared with me a while back. He was sitting in a meeting with a client and his top project team. A piece of QA within the release process for their code had broken down their process, preventing them from essentially, getting shit done.
That’s generally bad.
My good friend recognized something very critical though - why was backend regression testing (the piece of QA in question) occurring for the UX component of the software? They had nothing to do with one another, but were on the schedule and continued to be done.
The response from those around the table was basically, “that’s just how we do things.” Yikes! That answer, right there, can sum up a lot of what’s wrong within long, severely drawn-out release cycles.
We’re trying to get a v1.0 out the door, and will probably end up doing so this week. Now, we’ve been working on this (from the ground up) for the last, say, 2 1/2 months. That’s an incredibly short period of time to a) define a product b) get it through a development cycle c) market it, and d) release it. If, at any time, my response to a question had been, “that’s just the way it’s done” and thus prevented us from completing a key piece of the PDLC faster, I’d have expected I’d be fired partway through the process.
These types of excuses can be directly tied back to a few things:
- Egos - people want to cover their own asses
- Straight-up stupidity and fear - people don’t understand their role / job and are afraid to say, “I don’t know”
- Fear imposed by higher-ups - VPs and directors with no clue and way too much leeway to say, “my way or the high way”
- Silo’d, non product-centric organizations - those that define the company around roles instead of products
That last one is very important and one I remember touching on before. Agility isn’t just about having senior-level developers you can trust with flexible requirements, but it’s about everyone caring and contributing to the products themselves.
Who cares if someone is “in marketing” or “in legal?” Why does that matter? Their sole function is to solve pain for your customers and build great product. That’s why it’s so critical to commit to product management and not make it a half-assed effort just because everyone else is doing it. Get them in the center to do what they do - ensure the planning is place and crap makes sense, and then execute.
I digressed quite a bit, and it’s got nothing to do with how Scott’s post is written. The difference between using waterfall and using agile approaches is very simple - at least in my mind. If you have a complex, workflow-intensive product (like a banking or insurance-level application), you should be planning your PDLC’s using waterfall methods. If not, plan your whole PDLC using agile. No question.
Of course, that’s not to say, product groups within the overall (probably silo’d) organization that make up the individual feature teams or “product” teams if your suite is broken down that way (a la Microsoft) can’t use agile. They should. It would probably help them work faster and more closely together.
Sorry, Scott — I started out by intending to respond to some of your key points, but kinda got off on a tangent.
