Analytics

How often do you take time out to break down important data about your product? It’s easier than you think: [Web] Analytics According to Captain Kirk.

What do you want to read about?

Hello. We’ve been at this for a couple of months now, writing about various PM related (and sometimes unrelated) topics. And while we will continue posting as we see fit, we also want to hear from you about what topics you’d like us to cover.

Now that may be atypical of blogs, to ask readers what they want to hear about, but being Product Managers, it would be unnatural of us not to ask.

Is there something about Product Management or Development or Innovation that piques your interest? Want to know more about product pricing, positioning, process or partnerships? Any interest in SaaS or Agile? Want to know more about designing demos? Got a burning question you want to ask?

• What would you like to read about?
• Is there anything we’ve written, that you’d like to see more of?
• Is there anything we should stop writing about?

Let us know.

How to be a GREAT Product Manager (part 1)

There are a lot of good posts out on the Web about hiring product managers. One of the most popular ones that I’ve seen can be found on the blog HeyNorton, entitled “How to Hire a Product Manager“. In it, Ken writes that hiring managers should do or look for the following:

1. Hire all the smart people
2. Strong technical background
3. “Spidey-sense” product instincts and creativity
4. Leadership that’s earned
5. Ability to channel multiple points-of-view
6. Give me someone who’s shipped something

In summary, hiring managers should look for smart, technical and creative people with good instincts and leadership skills, who can assimilate multiple inputs and who ideally have been product managers before. Not really rocket science eh?

To put it even more succinctly, if you’re looking to hire product managers, then hire good people who’ve been successful product managers before. OK, I may be need to give Ken some slack, as he does explain each of the points in some decent detail and provides sample questions to ask prospective candidates. None of the questions are too tough though, assuming the candidate has a decent skill set and done some reasonable level of preparation.

So that’s how you hire a great PM.

But, how can you be a great PM?

To answer that question, over the coming days, I’ll present a list of analogues to Ken’s list. Today is part 1.

Don’t just sound smart, act smart and be smart

The vast majority of product managers have no shortage of intellectual capacity. Or to put it another way: a very small number of PMs I’ve encountered have been absolute dolts. Yes, there were a few dimwits, but then honestly, in any group, there are always a few aren’t there? In general, there is no shortage of brain power in the Product Management community. But the real issue is not sheer intellectual horsepower or the ability to articulate what should be done, but the capacity to turn all that potential into a kinetic form that does the right thing.

Nothing shreds the credibility of a PM more than the perception — let me repeat — the perception that he/she talks the talk but doesn’t walk the walk. It doesn’t matter how much of anything you do, if are not viewed as someone who rolls up their sleeves and digs into details, you’re fodder for the dart board.

If a development manager asks you to clarify a requirement, and you can’t give a sufficient answer, don’t try to hum and haw your way through it. Tell them you need to research that question a bit more, then get right on it and get back with a clear and well-reasoned answer in short order.

On the flip-side, when it comes to providing information, know when enough is enough. There’s no reason to write a 60 page requirements document with dozens of requirements, when, because of development headcount or time constraints, only 5 of those requirements have any chance of getting into the next release. Who are you trying to impress? And if you didn’t know that only about 5 requirements could make it into the next release, you have much larger problem to deal with.

Saeed

Part 2 - Be technical without becoming a technologist

Frames of Reference

You’ve heard of the Doppler Effect right? No, not the Doppleganger Effect, but the Doppler Effect. Probably the most common example of the Doppler Effect is experienced when a vehicle with a siren approaches and then passes you on a street. The pitch of the siren decreases suddenly as the vehicle passes you. Of course, to the driver inside the vehicle, there is no change in pitch. And to the person on the street that hasn’t been passed by the vehicle, the pitch has yet to change.

The Doppler effect is fundamentally about frames of reference. The frames of reference of the observers in the street are very different than that of the driver. Thus, they perceive and experience the same physical phenomenon (in this case the siren), quite differently.

So, what does this have to do with Product Management? Everything.

Being an effective product manager means, being able to get into the frames of reference of others, understand their experiences, needs and wants, and then assimilate that information and convey the necessary information to those around you who need it. If you can’t do that, then your product or release may get reinterpreted many times over by each team involved. One of the most famous examples of this problem is the famous tire swing series of cartoons.

Try something. When you are at work at your desk, get a chair and stand up on it (or stand on your desk if that is safe) and survey the area around you. Does it look different? What do you see from that frame of reference that you never noticed before?

Subtle changes in frames of reference can have a big impact on what you observe and what you understand. Consider people who work in data centers. To some, the most important part of the data center are the servers executing code. To others it is wiring, network cabling and switches that connect those servers to each other. To others it is the storage that holds all the data needed by the servers and transmitted over the network. To others, it is the cooling systems in the data center, without which the servers would overheat and shutdown. Each has their own priorities and their own frame of reference by which they view the data center.

The same is true inside the enterprise. Different teams view the world very differently. A CFO is focussed on net profit and loss and booking revenue. A VP of Sales is more focused on booking sales. Revenue and profitability are secondary concerns. A VP of Engineering is focused on delivering quality product on time. While each of these people are typically very concerned about the success of the company, their focus means they view success differently. Product Managers need to understand the differing frames of reference, and then be able to shift between frames as they work with members of different groups.

When I first became a Product Manager, I was having a tough time dealing with a number of the sales people in my company. I didn’t understand why communicating with them was so difficult. When I spoke to the VP of sales about the issues with his sales team, he gave me some advice.

“Salespeople are coin-operated. Remember that, and you’ll have no problem working with them.“

I took his advice and it worked wonders for my relationship with the sales team. Why? Because I stopped talking to them from the perspective of a Product Manager, and started communicating with them in their own language and in their frame of reference.

What’s the deal with BizDev? pt. 2

James McGuirk left a detailed comment on my original post that warranted a response.

Nicely written article and one that addresses the likely perspective of a product-oriented organization. Fundamentally they have interest in cultivating relationships with larger vendors which inherently increases the possibility (at least) of expanding the channel.

Thanks, and yes, correct, though I’d have to say it is from the perspective of a market-driven product organization. i.e. the clash between an overall market focus for products vs. a deal-driven partner/customer focus is the crux of the problem. As I mentioned in my comment to Mike Sabat:

In a sales driven company, product follows the transaction. i.e. the company builds the product to fulfill the transaction criteria.

…

In a market driven company, which is where Product Management looks at overall market needs (and not strictly at individual customer needs), the transaction follows the product. i.e. the company sells what is built with little or no modification.

While sales-driven and market-driven may not sound like they are too far apart, they are almost complete opposites when thought of from an operational perspective. But I digress.

James continued:

My perspective on business development however is derived from the vantage point of a systems integrator, where there are significant differences between services and product. As someone who has spent over 20 years within federal business development, the term implies an understanding of all aspects of winning business.

Companies that sell services, or sell products which include services, are almost always transaction-oriented, and therefore sales driven. I can sell you my generic product, but also sell you services to customize the product for you in some way. As soon as the services component comes in, even if the service is simply to help someone choose a product, the particular needs of the individual customer drive the activity.

In aggregate therefore, business development experts within the federal marketplace should have all those aforementioned qualities to be successful. Suffice it to say because of the level of comprehensive knowledge required, their expertise is always welcomed. Hope that helps. Jim.

The aforementioned qualities laid out in James’ comment are: Sales, Marketing, Capture Management, Proposal Management. What James describes is a different type of business development than what I was describing. In a product development company (vs. a services company), BizDev is usually part of of the Channels organization. It’s goal, as James mentions, is to expand the channel. But the issue that has frustrated me is the way many BizDev managers go about it.

Sales people are told to sell the current product. They can’t sell futures and they can’t make promises of future functionality, even if it is “on the roadmap”. But BizDev managers aren’t always held by these rules, even though they are fundamentally also sales people. I’ve seen too many cases where they sell futures (in the name of being strategic), and they discuss issues that are way off the roadmap — like the IBM mainframe port I mentioned previously. When this happen, serious misalignment occurs.

I have no issue with BizDev or Strategic Alliances in general. I see the need for them clearly. But I also have the responsibility as a Product Manager to do what is best for the product and the company. And much more often than not, that means saying “No” to rogue BizDev managers (and even, with some professional risk, Senior Management), when they go “off roadmap” and start looking for that “company making deal” (I’ve heard that phrase far too often) with some gargantuan organization that frankly, is going to waste a lot of our time, and is unlikely to ever close the deal from their end.

Lessons from Harry Potter

So tonight is the big night for all those muggles who have waited for the final installment of the Harry Potter series of books. To all those Harry Potter fans, I hope it was worth the wait and anticipation.

With the exception of the much heralded Windows 95 release, and I guess the recent iPhone release (though that technically isn’t software), I can’t recall a software product that has had people waiting in line at midnight in stores to get their hands on it. Again, not technically software, but the XBox releases did cause lineups, and in some cases, chaotic situations at retailers.

So the question is, how can a book have this kind of impact on so many people worldwide?

In short, it is the “user experience” that drives this kind of reaction. On a secondary note, it is the clever marketing that multiplies the demand.

In the case of the Harry Potter books, it is the characters, the world and the attention to detail that provide such a rich user experience for the reader. One could almost call it an “immersive environment”.

I remember playing Doom, way back when, particularly deathmatches over our internal network against coworkers. We’d play for an hour straight, but it would only seem like 15 minutes had passed by.

These kinds of experiences are not restricted to books or software. Virtually any form of interaction can become immersive in some way. I remember going to the theatre to see the Fellowship of the Ring when it came out. I had read the three Lord of the Rings books (a few times) as a teenager and loved them. I really was looking forward to seeing the movie, and it didn’t disappoint. The lush imagery of Rivendell, the battles in the mines of Moria, the ending with the battle against the Uruk Hai and the separation of the Fellowship, the personalities of the characters, and the attention to detail in the scenery were all wonderfully done.

Three hours passed, and as the movie was ending, I still wanted more. Why, because even though it was a fantasy movie, it was almost completely internally 100% consistent. I didn’t, at anytime think the Hobbits were simply actors made small through special effects. I didn’t think at anytime that the actions of the characters didn’t make sense. I was willing to suspend disbelief and accept that a fantasy world of Elves, Dwarves, Humans, Hobbits, Orcs, Wizards and the like could be real.

So getting back to software, particularly business software, can there ever be such a rich user experience that can drive demand in the way there is for books like Harry Potter? I think the answer is yes? Why can’t there be? Of all the media we have, software has the potential to be the most totally immersive. Not only can software provide rich aural and visual stimulation, it is truly interactive, responds to our actions, and can stimulate parts of our brains that books or even movies cannot. But in order to do so, like other things, it has to be internally self-consistent.

For software that means, it must be logically laid out, and intuitive to use. I shouldn’t have to move my cognitive frame of reference back and forth, from the software environment, back into the real world to figure out what to do. Once inside the software mindset, I should be able to get my job done in a natural and logical manner. Good software can be built to make that happen, but most of the time we cut corners and get a bit lazy or run out of time and expose all the rough edges to users.

Imagine if J.K. Rowling did that with the Harry Potter series. What if she decided that for the sake of time, she’d ignore aspects of characters revealed in previous books and make the characters behave differently from what the readers had come to expect? Or what if she decided to change her mind about the relationship between Harry and Voldemort, because it would take too long to write, and her publisher had a deadline to meet? The answers are obvious.

When we create software, we really need to take a step back, and get inside the users mind, and think about how to create an experience for them that has the hallmarks of a great book or a great movie or a great video game. We know what they are. The challenge is, how many of us are willing to invest the time and effort to make it happen.

Saeed

On Product Design

I was going to write a big entry about ethnography as a design tool, but that got me to thinking a more basic question: in your organization, who does product design?

First, we have to define “design” a bit more clearly. I’m talking primarily about software products here and I’m talking about under-facing interaction design. Not user interface design, because that the term “user interface”, while common, doesn’t really capture the more extensive idea of user interaction, which is more than just where the buttons are on the screen.

So, who’s doing it? You? A developer? If so, do either of know what you’re doing? Really?

Let’s check the Pragmatic Marketing grid:

Hm, no design there. And your developer? Does he (or she) really know anything about design? Maybe, maybe not. My point is this: it’s my experience that most software development organizations, especially “enterprise” software, lack any product designers. There’s a developer with a flair for it, there’s a graphic designer that you wrestled away from marketing for a day or two to do your icons, but there’s really no one doing serious interaction design.

If you’re a web design firm, things are different. Web designers, typically being consumer-oriented, are very focussed on user interaction as well as graphic design. Look at how we describe them: “web” “design” firms. It’s about the web and it’s about design.  Only recently, with the surge of interest in DSLs like Rails, have these web people have been doing anything interesting from an engineering point of view. So the web people seem to have it all these days. But in enterprise software, things are not so great - it’s about “enterprise” and “software”; “users”, “design” and “enjoyable experiences” don’t come into it.

So I’ve made the unsubstantiated statement that software development organizations lack interaction designers. But all is not lost. There’s a lot that you, as a product manager, can do to improve your product without resorting to pretending that you’re an interaction designer.

If we refer back to “The Grid”, there are three items right in the middle that form the foundation under any design efforts: “User Personas”, “Use Cases” and “Buyer Personas”. There are some very good books that talk about persona-based design, like Cooper’s “The Inmates Are Running The Asylum.” Building strong, compelling personas is an essential step to building a product that has clear, compelling value to prospective users. I saw this firsthand when Alan (Armstrong, not Cooper) put together the personas* for PerformaSure (he and I did a lot of customer calls together for this).

How do you build these personas and uses cases? By talking to a lot of users. But not just talking to them without any sort of plan, You need to build an ethnography.

* I like using the latinate “personae” instead of “personas” but avoid doing so in actual discussions at work because it sounds somewhat pretentious. Even though it’s correct.

Product & Market Alignment

blog.pmarca.com: Book of the week: Best book for tech entrepreneurs this year

Marc Andresseen recommends “The Four Steps to the Epiphany” by Steve Blank. Marc’s summary: “Steve proposes that companies need a Customer Development process that complements their Product Development Process. And he lays out exactly what he thinks that Customer Development process should be.”

Sounds good. I gotta get me some of that.

Structuring a Product Management Team (part 2)

In a comment on my original post on Structuring a Product Management Team, Josh Lannin made some good points I want to respond to. First of all, thanks Josh for the comments. I also have a few other thoughts on the topic, so here goes.

[Josh] Don’t underestimate the importance of assembling a team to actively change a pure technical engineering company as you describe it to one more sales focused or vice versa to the benefit of the business.

Agreed. The PM team can have a lot of impact in changing the company for the better, but in some cases, it can also be a long tough battle that in fact, may be unwinnable.

Some companies can succeed because of their technical strength, and in most of those cases, because of the vision of the founder. Sometimes this is a good thing, and sometimes this not. I know of one software company which is a leader in it’s field, it’s technology is well regarded, and it does in excess of $50,000,000 in revenue annually. Everyone who knows anything about that company also knows that it is a technology driven company, the founder rules it with an iron fist, and there is very little anyone, Product Management or otherwise, could do to change it for the better. While this is an extreme case, technology driven companies often suffer from “founderitis” — the inability of the founder(s) to let their puppy grow on its own. Changing this internally can be a huge struggle.

[Josh] As well, to build a PM team you have to look at people first because you can’t effectively fit square pegs into round holes. Product managers can have a very diverse set of skills and personalities- making them effective with those skills is often more important than bending them to a particular vision of how the org should look.

Yes, when looking at any team, it always comes down to the people. And in an ideal world, we’d have the roles well defined and find the ideal people for those roles. That, unfortunately is rarely the case though. Product Management teams tend to be small, and so every person on the team can have a huge impact, or if they are subpar, create a big gap.

The roles need to be defined in a structured way, and then the people found to fill those roles. Of course, if you come across an exceptional candidate who can contribute significantly, you bring them on if at all possible. But again, that is usually the exception. In creating a team, you want to ensure that the team can not only deliver on their objectives, but that the team can be resilient to change or disruption. If someone leaves, is the team structured in a way that a replacement can be easily hired to fill the gap? If not, then you have a problem that may be hard to address. Structure the team so that roles and responsibilities are clear and that no one Product Manager has knowledge that is difficult to replace, should they leave.

[Josh]With my group, we are focused feature first- because the most important thing for us to do is make sure we have good, non-overlapping coverage of functional areas when working with engineering.

This is probably the most common way I’ve seen for segmenting up a Product Management team. There is clearly a lot of value in doing this. If a particular PM has full “ownership” over a feature area, then they can focus on end-to-end functionality and entire lifecycle of that feature.

The downside is that not all product managers are capable of end-to-end management, particularly for complex products. I once worked on a large enterprise product. Initially I was the sole PM for that product. After a while we hired other PMs to take on some of the load. Initially we were feature focussed. A couple of the product managers were weak in this regard. While quite capable in general, they didn’t have the interdisciplinary skills to oversee all the aspects (client, server, mid-tier, security, metadata interfaces etc.) of their feature areas. The result was that someone who looked at the full product could detect the differences in various functional areas, and certainly integration points across those functional areas were not as strong as they should have been. While it has some advantages, the functional area focus does tend to create knowledge and development silos that can weaken the overall product.

[Josh]There is another aspect of product management teams that involves your critical blocking and tackling when it comes to requirements, release planning, watching the sales pipeline, etc. This can be a different skill set than a hands on product innovator role with someone that enjoys detailed work less than trying innovative applications of technology.

Yup. Some people like details, others are best suited flying at about 30,000 feet. Again, IMHO, this goes back to the roles that are defined. If I could get headcount to have a mix of PMs, some of whom are better at the details, while others are better at finding innovative applications to technology, I’d be happy. My experience has been that the PM teams don’t have that luxury. Making the case for it is certainly possible, assuming a receptive management team, but in my experience, it is a tough sell.

Product Management teams are typically woefully understaffed in software companies. That is part of the problem in building teams. Adding another PM is a tough sell. Adding another engineer or sales consultant or sales person is far easier sell. I wrote about this in Product Management Maturity.

For highly technical products, say targeted at Enterprise IT or datacenters for example, I like the model of having both Product Managers (PM) and Technical Product Managers (TPM) (sometimes called Solution Specialists, or Solution Architects) working together in the PM team.

The Product Manager is responsible for overall product direction, roadmap etc. The TPM (or other equivalent title) is responsible for supporting the PM work through some of the more detailed technical aspects of the product, or competing/complementary technologies etc. The combination of the two, makes for a strong team, but also makes it easier to hire for each. Finding one person who can do both roles very well can be difficult.

My original post was meant to cover some of the key questions that should be considered when trying to structure a PM team. Given that PM teams tend to be small, and the role of Product Managers is not uniformly set across companies, it’s hard to come up with a standard model for a PM team. Going forward, as the role of Product Management is better understood and the practice matures, more standard models for team structures will appear.

Saeed

Structuring a Product Management Team (part 1) 

Cranky Kid 1.0

Just a short shout-out to the Cranky Product Manager who has apparently released Cranky Kid 1.0. I won’t divulge the breakdown, but I believe the three of us have 10 kids among us. Our spouses would count 13 I suppose.

All the PM-baby jokes that should be made have been made, so I’ll leave it at that.