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.
Board Meetings
I gave my first board meeting presentation this past week. I won’t lie and say, “no big deal.” It was, and I was nervous. I attempted to find some articles in the regular product mgmt spots online, but no such luck. Hopefully my posting here will be able to help those that will go through this process as well.
I had 30 minutes to present, and needed to cover 8 of the 11 products in the portfolio, including demos for 2 of them and high-level roadmap for each of the 8. It’s easier than it sounds.
I did manage to get lucky, because our board is very well informed. I do spend time speaking to most of the members on a regular basis, especially as we close in on a launch. They all take a great interest in our products, and support our team with great feedback, and actually going out to get feedback from others. It rocks, and really makes my job easier.
So, what did I put together? I toyed with a couple of different formats, but landed on something similar to this:
| Product Group | Product | Current Status | Roadmap |
| Group1 | Product A | v2.0 (Shipped: June 1, 2007) |
In Dev:
Backlog:
|
This was a simple word doc going through all ~8 products I have on the docket, and I had handouts for each board member that was present. When I got to a product I had to demo, I’d flip to an open browser window and go through a really short / focused demo. I’m super lucky because our chairman would jump up and talk through some of the more expanding / larger business issues or customers he has been talking to recently.
I faced a couple of questions, but not too many. This was a factor of not having a ton of time, but also having well-informed board members I was speaking to. It was a true briefing / update.
I’ll be the first to admit, I didn’t have all the info in a format like this previously. It usually stays all up in my head. It was good to get it down on paper, if for no other reason other than I had to. But, I think the format was good as well - going with a long PPT deck / stack of slides talking about each product, and the definition surrounding it, would have been a major waste of time.
I covered each one, and got some great feedback that it was exactly what was needed. Some other advice:
- Know your stuff. The better you know what you’re talking about, the easier it is.
- Let everyone say their piece. Even if it’s something you’d already thought through and discounted, accept the feedback (”thanks for the feedback, we’ll take it into account”), write it down, and move on. Don’t argue / refute and make anyone feel stupid.
- If you are in a start-up and have a penchant for french cuff shirts (umm, this is me), don’t wear one. Please. You aren’t Sam Palmisano headed to the annual shareholders meeting.
- If you don’t know, say you don’t know and will follow-up.
- Don’t slouch in your chair. Sit up straight and talk with confidence. You don’t want to look like you just finished playing 18 holes at the golf club on a Sunday afternoon and are having beers with the guys / gals.
Hope this can help someone for their next / first board presentation. It will probably always be nerve wracking, but I think so long as you really do know what you are doing and aren’t faking it, you’ll be 100% fine.
Pricing Strategy Tied to EOLs
EOLs (end of lifes) on product lines, especially multi-product portfolios, are a fact of life. So, how do you deal with pleasing customers of a product line when only 1 product from that line is being dropped.
You do exactly what Apple did yesterday with the iPhone.
This was great because, while they did make a couple of people angry, the leveraged a short-term refund policy for those that really did just buy iPhones yesterday, but they managed to smoke one product off the iPhone line.
But the big news isn’t about the EOL — it’s about the price drop. Could they have killed this one product off better? I don’t really think so.
So, clearly there were enough people willing to spend some bucks on the smaller iPhone, but the price reduction should be enough to not only allow those folks to buy the iPhone, but also spend a little bit more than they were going to originally.
I wonder if this applies to Web applications? It would probably be a little tricker to execute, but you could do it. If you had two streams of a subscription product and wanted to EOL one of them, you could totally drop the price of the bigger / badder stream to catch the customers that were either about to purchase the smaller one, or in the process of thinking about the smaller one.
But, the tricky part is, because the subscription isn’t tangible, do you get the same effect? Well, the upgrade would work the same. You keep the limited functionality of the lesser-price subscription stream around indefinitely, and offer users that just bought the cheaper one 30 days ago (for example) a free upgrade for 6 months or something.
Very cool stuff. Well-executed product marketing strategies right before our eyes.
Now, if I lost my mind and bought a “Vista-ready” PC, would I go for Vista flavor 1 or 8? Hmmmm….see, there are never-ending arguments to Apple vs. Microsoft. But the one that’s ultimate for me is one of slickness / sexiness and this iPhone EOL is case in point.
The product and strategy are so damn slick, that no one even really cares they are dropping a product and refunding a small group of customer base. At the end of the day, the customers are still investing in a very cool looking product, which is satisfying. OS X may not have the 1,00,000,000 features Visa versions 1-8 do, but damn it pretty much rocks the core fundamentals of an OS, and looks really good while doing it.
So, while the whole Apple EOL / pricing thing that just happened yesterday is a great lesson to learn from, the other one is, don’t ever discount keeping things simple, and the cool factor.
Happy CTO & CEO - Where’s the PM?
Jason Calacanis posted today about having a happy CEO and CTO relationship. While I don’t dispute Jason as being one of the best in the biz, and I would love to get to work with him at some point, I have to point out something that I feel is missing. Maybe intentionally.
But first, let me say this - I haven’t been in nearly as many start-ups as Jason, nor have I had the experience he has. Surely, take his word over mine. But, being a product manager, I feel I have something to add.
I’ve been very close to some “interesting” CEO and CTO relationships during my career thus far. Sure they could have either been salvaged, or not even allowed to get to that point, by following some of the advice Jason provides us throughout his blog post. And all of Jason’s points are totally bang on between the CTO being concerned about the system and the CEO being concerned about shiny / “wow” (I hate that term) appeal.
While these parties need to have an effective working relationship, if you insert a product management leader in to the mix, everything becomes a little different. You end-up (or should end-up) with someone that can see both sides of the equation. The CEO doesn’t want to have his head in a vice at the next board meeting for not getting the million-dollar feature out the door and closing the next million-dollar deal, while the CTO doesn’t want another night away from the family tending to nasty server downtimes at the remote data centre.
Can’t build a house on toothpicks…
Now, the interesting perspective the PM leader should bring is, “what does the market want and why?” Now, I’ve seen multiple times the “suits” not really giving a crap. They want it done, and want it done now. But is the reasoning in the best interest of themselves or the company? It sounds so cliche, but it’s true.
Now, if you have a CEO running around yelling at the CTO to just “get it done” because they say so, this is a poor structure, and sure to fail. Both CTO and CEO should understand what their roles are and involve a product manager (should the organizational structure support it — it should, and I’m bias).
If the CEO can’t stand-up to their boss(es) and explain where progress is being made, and yes - it’s a little pragmatic, but “Rome wasn’t built in a day” and all that business, the CEO should be questioned in his or her ability to lead. At least in my opinion.
Breathing down a product or a dev team’s neck just because a nasty board member with a penchant for yelling says, “who cares about the customer with the problem, I want my new Mercedes and my liquidation event” creates bad vibes and, probably, irreconcilable differences.
So, at the end this mini-rant: listen to Jason. CEOs and CTOs having a good relationship is critical to the business succeeding. If you have a product management leader in your organization, they should always be consulted for guidance relating to the market. More often than not, they are playing air traffic control, and should know what’s happening anyways.
I’m not advocating the PM replace either C-level officer, but they do have insight into feature priority and in software organizations, and they should have some level of technical expertise.
See it from both sides. Does what you’re freaking out about solve a real problem or pain? The concept sounds nice, but being market-driven usually fails in execution. Is the market in demand for the feature? Can it be solved in a technically feasible manner? All of these questions (and more) are reasonable reasons to say, “implement” and/or “kill it.”
So, great post Jason. I hope i don’t sound like a raving lunatic who dreams in market data and prioritizing features.
