Every once in s awhile I find articles about my current role at AppFog to see how I align. The gist is quite applicable, but this has to be transformed to be more applicable to a scrappy startup as opposed to a large corporation for which this was written.

Good Product Manager

Bad Product Manager

By Ben Horowitz and David Weiden

Note: this document focuses specifically on product management in the context of a “divlet” [small division] in AOL.  Related key assumptions are that there is a corresponding “business owner” in each of the brands, and that the “products” are generally online services intended for individuals.

A Good Product Manager plays critical role in a successful product.  A successful product is the highest impact contribution that anyone can make in the PD organization.  In fact, the number one criteria for selecting a Vice President is the candidate’s track record (or lack thereof) of successful products that become profitable businesses for their company.

Being a good product manager is so hard that most product managers at most companies fail to be good — and instead are bad.  Because product management is a highly leveraged position, a bad product manager leads to many other bad consequences, generally including the wrong product being built, which generally has a significant impact on revenue, morale, and reputation — of both the product manager and their company.

There are a number of straightforward principles that product managers can follow which will dramatically increase their chance of success.  Surprisingly, only very few product managers follow these principles.  Part of the problem is that these principles often are not articulated clearly, which this document attempts to address.

A final note is that product management is a demanding and high profile job.  Individuals should make sure they’re up to the challenge.

Summary points:

• CEO of the product
• Balance all important factors
• Clear, written communication with product development
• Clear goals and advantages
• Focus on the sales force and customers
• Other key skills
• Really good product manager

CEO of the product

• A good product manager acts like and is viewed as CEO of the product. CEOs drive vision and are ultimately responsible for their company’s success or failure.  The same is true with a good product manager in relation to their product.  Good product managers have a realistic vision of what success of their product means and they ensure that this vision becomes reality – whatever it takes.  Good product managers are viewed by the entire product team as the leader of the product.
• Bad product managers think of themselves as marketing resources. Bad product managers define their role narrowly as a marketing resource: someone who writes data sheets, arranges press releases, gets customer feedback, etc.  Bad product managers get all of their time sucked up by the various organizations they work with, they take product team minutes, they are gophers for engineering.
• Bad product managers have lots of excuses: not enough funding, the engineering manager is an idiot, Microsoft has 10 times as many engineers working on it, I’m overworked, I don’t get enough direction.  Once bad product managers fail, they point out that they predicted they would fail.  Barksdale doesn’t make these kinds of excuses and neither should the CEO of a product.

Good product managers balance all important factors

• Good PMs take all important factors into consideration. As CEO of the product, the product manager must understand and balance a wide variety of factors that affect product strategy and execution.
  • The primary factors to balance include:
    • Company goals & capabilities. Good product managers understand (or seek guidance on) overall company goals and set product strategy in that context.  Good product managers also understand the capabilities and limitations of their overall company.  For example, a good product manager knows if their company wants to maximize per deal revenues through a high-end direct salesforce to a few hundred customers OR if the company wants to maximize customers with an easy-to-use product for hundreds of thousands of customers through a diverse reseller channel.  A good product manager also knows  approximately how much and what kind of marketing resources the company will spend on these products.  Good product managers don’t always know the answer to these questions, but they know enough to ask when they don’t.
    • Customer demand
      • Good product managers listen to customers but they probe deeper into the underlying problems to get at the compelling value proposition for the customer.  If you had a noisy car you might ask for a louder stereo, but you would probably be a lot happier with a quieter car. A good product manager gets at that difference.  Good product managers also know what customers can & will pay for (sometimes that’s slightly different than what they want).
      • Good product managers do quantitative research.
      • Good product managers are certain that if they build a certain product, customers will buy it.  Good product managers understand that if they screw this up, they might as well pack it in so they go the extra mile to make sure they get this right.
    • Competition. Good product managers understand the architectural and business capabilities of the competition and know where the competitors can go easily and can’t go at all.  Good product managers know they must be better or different or they’re dead.  Note “different” can mean things other than product differences, like integration or distribution..
  • Know what you know and what you don’t know. A good product manager is acutely aware of what they know and why they know it, as well as what they don’t know.  A good product manager understands the difference between opinions, hunches, and objective facts.  A good product manager knows that their job is to fill in these gaps in knowledge, not to defend or obfuscate them.  A good product manager doesn’t ruin their credibility by over-stating their knowledge.  Note: Tim Howes contributed the word “obfuscate,” so don’t blame marketing for that.
  • Think ahead and monitor your assumptions.
    • Note all these factors need to be considered both now and over the lifetime of the product.  That is usually 1 – 2 years from now.
    • Good product managers also know what their important assumptions are and they monitor them from time to time to make sure they still hold.  For example, if a server product’s success assumed dominant client marketshare, the product plan should be re-evaluated as soon that assumption is threatened.
  • Good product managers will actively confirm their understanding with their managers and others on their team.
• Bad product managers miss the big picture or miss small but important factors. Bad product managers build a good product for a market their company isn’t in.  Bad product managers build a product that’s too complex for their company to sell.  Bad product managers build a product that will take too long to pay off.  Bad product managers ask customers leading questions and get biased answers. Bad product managers go on their instinct and “confirm” it with two unusual customers.  Bad product managers react only to the moves of their competitors and forget to develop their own product’s identity, letting it be just a hodge podge of what the competition is not doing.  Bad product managers aren’t savvy or confident enough to distinguish between interest and commitment to buy.  Bad product managers blindly listen to the loudest customers, and define a product that addresses yesterday’s needs of a handful of companies.  Bad product managers compare future products to today’s competition, or cite advantages customers don’t care about.  Bad product managers try to defend their lack of knowledge rather than gain the knowledge.  Bad product managers have blinders on and don’t notice when things change and notice only when their product fails.

Clear, written communication with product development

• Good product managers clearly define product requirements — in writing
  • One of the most important – if not the most important – job for a product manager is to define clearly and in as much detail as is necessary what the product should do, how fast it should be, etc.  Good product managers don’t forget to specify critical information.  Good product managers err on the side of clarity and are willing to explain the obvious to make sure it’s understood.  Good product managers also specify the whole product, including release criteria, platforms, etc., not only the new features.  Good product managers also sense and tackle hard issues – in writing – early in the development process.
  • Note a good product definition does not come down from a product manager in an ivory tower, but is based on research, information and a logical, transparent thought process that the entire team buys into.
    • Good product managers know that engineers are scientists by nature and value data much more than opinion.  Also, engineering and other parts of PD (QA, Doc, etc.) should be involved in that process.
    • Good product managers define a clear product vision and target that empowers engineering to fill in the details that are difficult to specify or anticipate.  As part of this, good product managers also explain why engineering should build a particular product a particular way.  A good product manager will not ask for a two ton collection of certain parts that will look a certain way and hope it comes out as a Porsche.
    • A good test of a product manager is for someone outside the product team to ask 5 different people in engineering, QA, and doc what their product is supposed to do and why and get the same answer.
    • Good product managers are respected by their engineering teams.  Engineering teams involve good product managers in difficult decisions.
  • Good product managers gather information from engineering informally and verbally, but good product managers give direction in writing to engineering..  Written communication to engineering is superior because it is more consistent across an entire product team, it is more lasting, it raises accountability.
  • Good product managers attend product team meetings regularly and make sure they’re around when engineering is making tradeoffs.
• Good product managers think their Product Requirements Document (PRD) is a big deal. The PRD is the single most important document the product manager maintains and in most cases should be the definitive source of direction from marketing to engineering (see Writing a Good PRD).
  • Good product managers keep PRDs up-to-date daily or weekly at a minimum.  Good product managers view the entire PRD process as a living ongoing process, because it is (engineering has new questions, market conditions change, etc.).  If anything changes in the PRD, a good product manager communicates the change clearly to the entire product team.
  • Good product managers don’t rest until they are sure that the product vision is consistent across product management, engineering, QA, tech pubs, and support and is reflected in the PRD.  They don’t rest, because they know that no great product ever emerged from a broad set of conflicting visions.
• Bad product managers cut corners on communication with engineering or misunderstand their role. Bad product managers specify the how not the what.  They want light and ask for a candle when their engineers could have built a light bulb.  Bad product managers have a bad feeling about an aspect of the product but leave it murky.  Bad product managers worry about specifying every feature in detail thinking they know more about how to solve a problem or how the product should behave or be architected.  Bad product managers put off hard decisions until the end of the product cycle.  Bad product managers write a PRD and assume engineering understands it.  Bad product managers don’t have time to update their PRD.  Bad product managers update the PRD and don’t tell anyone, or don’t tell enough people, or don’t explain why.  Bad PMs change engineering priorities based on the latest customer feedback or latest hot sales situation without going through the defined process.  Bad PMs ignore engineering requests or calls.

Clear goals and advantages

• Good product managers have clear goals. Good product managers are absolutely committed to success.  Good product managers define success as achieving explicit goals.  Goals that are important are written down.  Good product managers have written goals for their product and for their own personal objectives.
• Good product managers know the advantages of their product cold. Good product managers know how their product will be better / different than the competition.  This comprises a key part of the overall product vision from day one and is reflected in most things the product manager does.  Good product managers have these advantages written down and are consistent.
• Bad product managers. Bad product managers have mushy goals and mushy product advantages.  Bad product managers hesitate when asked for the advantages of their product.  Bad product managers have inconsistent product positioning and advantages change from time to time.

Focus on the sales force and customers

• Good product managers are loved by the salesforce. A good product manager will be known personally or by reputation by at least half the salesforce.  Good product managers know that salespeople have a choice of products to sell and, at a higher level, companies to work for, and selling a particular product manager’s product is optional.  Good product managers know that if the sales force doesn’t like their product, they will fail.  Good product managers know that to win over the sales force they have to be some combination of:
  • Focused on making them money — good product managers focus on and understand that salespeople are under a lot of pressure to make their quota, this quarter, and that’s about it.  Good product managers understand most salespeople care about things in that context and not much else, so they put things in that context without making the salesreps make a lot of intellectual leaps.  “Bell Atlantic paid $3m for directory because of abc feature” not “abc allows referential integrity to be maintained across entries.”
  • Knowledgeable of what actually happens in the field — nothing turns off a salesperson more than a product manager who rambles on about their product features and seems to have no idea of the salesperson’s actual situation.  Good product managers know if the salesperson understands what the product does or not (and if not they start with easy to understand basics), if customers do (if not they explain more why a customer would care than what the product does), etc.  Good product managers speak from experience.  “When I helped Bob close this deal…”
  • Around –  they’ve been out in the field, been to sales training, been to SE training, been to pitches, etc.
  • A good presenter
  • Responsive
  • Fun
• Good product managers know and understand customers. Good product managers know a handful of current and potential customers personally.  Good product managers understand the exact dynamics of real customer situations.  Good product managers leverage this knowledge with engineering, other customers, the salesforce, press and analysts, etc.
• Bad PMs don’t have time for the salesforce or customers. Bad product managers focus on their product and competitors and aren’t sure what’s going on in the field.  Bad product managers delegate working with sales.  Salespeople have either never heard of or dislike bad product managers.  Bad product managers are boring presenters.  Bad product managers talk about how future products will be great, but the current products are weak.  Bad product managers don’t care about individual customers.

Key skills

• Marketing & communication
  • Product management requires an understanding of and proficiency in though not deep expertise of a wide array of marketing functions.  For example, good product managers should be able to work effectively with PR and press and analysts, understand how to execute a product launch, develop collateral, staff a tradeshow, train the salesforce, etc.  (See Working with Press and Analysts.)
  • A core rule of good marketing is to have clearly articulated advantages that are consistent across materials (ideally from the PRD to customers to sales, etc.).  Related to this is the importance of creating leveragable collateral, FAQs, presentations, white papers.  In particular, a product manager should make sure a core set of updated collateral exists (annotated presentation, written positioning, primary silver bullets).  If your primary competitor is abc and the most recent competitive positioning on abs is nine months old and refers to the last release of their product, this is indicative of a bad product manager.  Also, good product managers take competition into account in developing their messages, but are not a slave to what the competition does.
• Time management and sense of what’s important
  • Good product managers focus their time in two areas: 1) tasks that are critical to their product success (e.g., export approval, mandatory licensing arrangements); 2) tasks that have a high impact on their business (closing big deals, updating their PRD, etc.).  Good product managers also leverage their time by completing FAQs, having a standard annotated presentation, doing good training, etc.
  • Bad product managers put out fires all day.  Bad product managers complain that they spend all day answering questions for the sales force and are swamped yet don’t create FAQs or other leveragable collateral.
• Discipline
  • A lot of product management is ad hoc.  Good product managers respect a base level of discipline and organization in their work.
    • Good product managers keep their project up-to-date in Signposts.
    • Good product managers send their status reports in on time every week, because they are disciplined.  Bad product managers forget to send in their status reports on time, because they don’t value discipline.
    • Good product managers don’t over-promise.  Good product managers keep developers doing product development. They don’t offer engineering resources for things that can and should be handled by sales or marketing.

Really good product manager

• Really good product managers demonstrate group product manager skills and capabilities while they are product managers.  (See Good Group Product Manager / Dead Group Product Manager.)  These skills include:
  • Be paranoid.  Really paranoid.
  • Work well with executives.
  • Leverage the entire organization.
  • Use whatever intensity is required to close critical issues.

One formula I found to work well for writing a successful apology is to write three statements (apology, problem, solution) with the common thread of openness and accountability.

As a scrappy startup focusing on your core proposition you will cause some pain to your customers all while they still love the product. We’ve made a few of these mistakes, some big (leaving a security hole and getting hacked), some small (sending an annoying email to everyone). We don’t try to deny or hide any of it. In fact, the fundamental principle that runs through our veins is openness and accountability.

In cases where you owe your customers an apology, here is a formula that has worked for us.

(1) I’m sorry for…

First, you must confess that you screwed up. In the process you must take accountability and you must be open about the problem. This is critical; when you apologize you must identify what actually went wrong. It is critical because it is also a big opportunity to screw it up if you don’t do it right. For example, if by accident you send an annoying email to a customer (we did this once), you should say “We apologize for sending an annoying email”, the worst thing you could do would be to write “I’m sorry you felt annoyed by our email.”

(2) This is what went wrong…

Explain what went wrong. Again, there is a right way and a wrong way. This is where you can get your customers trust back. If you explain the issue to them in detail, they will feel respected that you confined in them and they will support your decisions. If you use this as an excuse you will not gain the customers trust as it will be clear that you are not taking accountability for your actions.

(3) This is what we are doing to fix this…

Lastly, you must make things right. At this point, you have better fixed the issue or have a clear plan of action. If you do not, this should be your number one priority. If you fixed the issue immediately, thats great, but don’t wait to have a fix ready before sending the apology. If you don’t have a fix ready, make a damn clear plan on how you will fix this. The plan is actually irrelevant, what you are actually doing here is making yourself accountable by telling your customers to make you accountable. You must deliver on your promises or you will lose your customers trust.

This formula works. What makes this work, isn’t the three pieces of data, but it is the common thread that runs through them: openness and accountability.

Here is a collection of some of the books that I think entrepreneurs (anyone starting a new software project) must read. Whenever I work on side-projects with friends (tech and non-tech) I tell them they should read these books. I’m likely to continue to update this list.

Pitching Hacks

This book comes as a recommendation in order to understand traction. Establishing traction, regardless of the form, should be the highest priority for starting a company. Without traction, a company is just a few signed pieces of paper and wasted time in developing a product. Once you think about how to show traction for your business, you will quickly realize your priorities and that much of what you that was needed (developers, an office, etc) is completely unnecessary.

The Entrepreneur’s Guide to Customer Development for Tech Startups

The fact that this is called a “guide” is spot-on. This book is like cliff-notes to The Four Steps to an Epiphany, which establishes the rigorous customer development methodology. This really does read like a step-by-step guide for building the minimum viable product.

ReWork

This is written from the founders of 37signals.com. I highly recommend this book for all software development teams, not just entrepreneurs. While the other two books help you understand your business and get it off the ground, soon you will need to get into a rhythm of execution. This will help you understand how execute building a product (priorities, choosing what to build and not build, deciding when to hire, working hours, etc).

If you are responsible for defining the product of your company/org your opinions (and thus ideas) don’t matter, customer dialog does.

As a product manager your job, among other things, is to define your product, that is, what the development team is supposed to build in order to satisfy the needs of the customer. This role can be disguised in many titles: Program Manager, Product Manager, CEO, etc. This has been my career for six years now both at Microsoft as a Program Manager and at PHP Fog as a Product Manager. In one case, Microsoft, there was very limited customer dialog (and damn it was hard to change that), and in the second, PHP Fog, I have a very rich dialog with customers. This had a number of downstream effects on their respective organizations and success. I want to share some of those observations in those two cases.

Microsoft: Limited customer interaction

1. To be successful you must have strong opinions. You must be the first to state the consensus conclusion during debates.
2. Product success criteria isn’t defined by product/market fit, it is defined by the most senior manager’s opinions/ideas (which are loosely correlated to product/market fit).
3. Product success/failure is not correlated to individual product success/failure.
4. You must persuade others to invest in ideas based on your arguments, opinions, ideas and research (not customer evidence).
5. The perceived leaders are those that voice their opinion first and loudest (quite literally).
6. Define fictional “scenarios” and “customer profiles” with fictional companies/names to highlight requirements.
7. You hear people say “In my opinion”, or “I think” and “customers want” (that last one is usually invented)

PHP Fog: Rich customer dialog

1. To be successful you must have strong customer evidence (sprinkled with some opinions)
2. Product success is based on market goals which we can measure
3. If I am successful as a PM I am making a very strong contribution to the success of  PHP Fog.
4. My team asks me what to build, and I merely rephrase our customers to make it actionable
5. The leaders are those that stimulate a productive environment and build relationships (team, partners, customers, investors, etc)
6. Product priorities and requirements are backed by countless pieces of customer feedback
7. Usually start sentences with “Customer [xyz] needs…”

Caveat: I am just highlighting the contrast, though at Microsoft some of those elements can vary in severity depending on the product.

As a product manager, if you want to build a successful product, start by throwing out your opinions. The magic is in being able to stimulate meaningful conversation with customers and making this actionable to the development team.