Steve Johnson on Product Management

More notes from another Business of Software 2008 lecture by Steve Johnson from Pragmatic Marketing. He talks about what product managers' role is, what they actually end up doing, and what they need to do, in order to be meaningful representatives of the actual product's users.

• Companies tend to start off as technology-driven, then become sales-driven (each new sale requires custom development), then become marketing-driven (lots of money spent on their brand image).
• Then they cut costs, and go full circle to technology-driven, and repeat the cycle. Good product management can help to break this cycle.
• Illustration of how wills are only executed: you are already dead when the will gets to court. So the document needs to be long enough to deal with all possible arguments.
• Application specifications have the advantage that the specifier is normally still alive when the development teams come to implement them!
• But we keep writing specification documents (product requirements, marketing requirements, functional specifications...) in order to cover all managers' worries/requests.
• The right answer is not to create more artefacts. Tightening your grip will mean more slips through your fingers. Instead it's to have someone who really understands what's needed, and can back up their assertions with evidence.
• Many companies are like Star Trek (original series): Spock (development) logical, trying to be human. Bones (marketing) upset about what he hasn't got, or what he's being asked to work with. Kirk (sales) always committing the ship to more than it can do. Scotty (product manager/sales engineer) lies to Kirk at all times, then says "OK, let's go!".
• Agile development crowd wants to improve these development/specification processes by having a customer representative on hand to try out each iteration on.
• Problem: most of us don't program for individuals. We program for multiple customers!
• Agile/Scrum methods seem to make us more introspective. We spend so long in development team meetings that the product manager does not go out and talk to the customers!
• Sales don't tend to understand why some of their development requests are not possible. An interesting idea is to turn this round and ask similarly unrealistic questions to sales. Example: "Why can't you give me a well-defined feature set by a guaranteed date?" is replied to with "Can you tell me what hour of the day and the exact amount that you're going to close this contract for?"
• In many cases, the only people who talk to customers are technical support. But are they talking to all of our users? (Hopefully not!) They're only talking to the people with problems, and not even all of them. What comes out of this? "Remember the 'L' in (L)user is silent". "Losers" are those who you have to teach basic computing to. "Power Losers" are those who are trying to use your product in ways that you never intended. But you can't just try to market to "smarter" users!
• Biggest contribution that a product manager can make is to be representative of users. That means the PM has to leave the building, and talk with users, and potential users!
• Causing customers to switch is one target, but selling to potential customers is hugely important.
• Three groups: current customers, evaluators (people currently shopping: only sales talk to them. If they don't buy, then product management analyses why), and the untapped potential market. The last group is very important.
• Customers tell us what new features they want, but potentials tell us what would convince them to buy. Get evidence for what features are really asked for by customers. That helps choose which of the many ideas that come out of our company are to be implemented.
• Development and Sales have different views of product managers should do. Sales tend to want people who can demo/explain the product. This is probably best done by sales engineers. (See Steve's post on sales people as order takers.)
• Work out what areas of the business that are thought of as product management are not actually officially assigned to someone at your company: they will be happening, but are they happening well, or "just being done"?
• Jargon: Inbound marketing is understanding what customers want the development team to do (product management). Outbound marketing is about actually selling the product (product marketing manager).
• The product management triad: executive direction, marketing, and technical management. All require different skills. May end up splitting into three separate roles.
• Sales people tend to think one deal at a time, which is as needed. But when sales comes back with a new idea, put it in the list of possible new features, but wait and see how many people actually want it, rather than just the one deal that that salesperson is currently progressing.

To me, it's interesting how broad the role of product management can be. It's also a salutory reminder that when two companies recruit for a position with the same name, it might well be for totally different roles...

Lessons from Hermann Hauser

Another interesting Enterprise Tuesday lecture by serial entrepreneur and angel investor Hermann Hauser (Amadeus Capital Partners). He talks about the mistakes he has learnt from in five of the 62 companies that he has been involved with: Acorn, ATML, Harlequin, ART, and Polight. Here are my notes and thoughts:

• Acorn spent its first five years not being able to produce enough computers to meet the demand. It therefore signed long-term agreements with manufacturers, and eventually met demand. Unfortunately, at this point the market crashed. Inventory piled up, and the company had to be rescued by Olivetti. Corollary: understand the variations in your market, and plan inventory sizes appropriately.


• ATML's initial product was (probably) the best 25 Mbit/s ATM switch on the market. This did not sell, as 100 Mbit/s switched ethernet soon arrived on the scene. Larry Ellison (of Oracle fame), invested in the company, and hence kept it afloat. However, the company began to make significant sales of its ATM to IP "conversion" chip to manufacturers of DSL modems. The business model was then changed, resulting in real growth. A merger with American company Globespan was proposed, but this turned out to be a bad move, as their management team was not as strong as ATML's (by this time Virata). Corollaries: product strategy needs to be correct (and malleable); don't assume that as a British company you need to be bought by an American company to succeed.


• Harlequin's aim was to build the world's greatest AI company, by producing a LISP interpreter. But this wouldn't be profitable, as it would be a small market. In order to obtain revenue, the company produced PostScript technology for printers. The founder refused to raise cash through selling equity, but wanted to raise debt. Natwest gave him a £5 million loan. That increased to £10 million. The difference between banks and VCs is that banks can call in the loan. Harlequin was sold for £1. Corollary: in a fast growing, high-tech company, you need equity, not loan, finance.


• ART (Advanced Rendering Technology) made a break-through in hardware rendering technology. Genereated photorealistic images for car companies. But there were only so many car adverts that needed making! Corollary: market size matters!


• Polight produced holographic storage technology. Unfortunately, a very gifted physicist on the team showed that it was in fact impossible to produce the technology that they were working towards. Corollary: sometimes the technology itself may be at fault.


• Time estimation: whatever you estimate, multiply by Pi to get a realistic estimate. Similarly, market size estimates tend to be very overstated.


• People-related issues are common: people fall out with each other surprisingly easily.


• Finally, keep making mistakes, but make new mistakes.

Personally, I think that much of the above is obvious in hindsight. In other words, I'm sure that ART were aware that they needed a big enough market in order to generate sales growth long-term, or that Acorn would not have signed manufacturing contracts if it had known that demand was going to fall. Perhaps the most interesting conclusions to be drawn centre around how ATML was nimble enough to change their strategy (i.e. that they were willing to sell that one chip that was a tiny part of their much more complex core product), and that they would probably have done better not to merge with Globespan.

So how to avoid the "obvious" mistakes when starting out? Clearly it's not easy. Here's my take, for what it's worth:

• Market trends & inventory: of course, the ideal company is one that has no inventory, and yet can keep up with demand. If you're selling pure IPR, like chip designs (e.g. ARM), that's great, because inventory becomes someone else's problem. In the case of a software company (assuming its products are sold for download, or online use, rather than on shop shelves), inventory perhaps becomes synonymous with how much server capacity you have, plus possibly support staff. Hence, using cloud computing services such as Amazon's EC2, (or their content distribution network, CloudFront) and outsourcing non-core work to contractors (as suggested by Seedcamp's Reshma Sohoni) provides much greater flexibility to respond to demand. Of course, reading market trends hopefully means that you're aware of what proportion of your services are "base load" and hence could be performed in-house.
• Product strategy: be prepared to admit that your first idea didn't work, but that a part you never envisaged could be valuable actually might be. Concentrate on your core competencies.
• Market characterisation: talk to your potential customers! I find it incredible that there are so many web sites that make it so hard to give good feedback once they're selling (and that's after they've decided on their product!). As David Langendries pointed out in a comment on my post "The Dangers of Online Feedback", companies would do well to pick up the phone. Most successful products are preceded by good marketing (distinct from advertising), says Seth Godin. Which to me, means that technologists need to be very sure they can convince the customer that their product solves a problem that the customer (maybe) never realised they had. And convincing means talking, rather than yet another online survey.

So there you have it: terribly simple, right? ;-). Then again, you'll find plenty of other conflicting advice elsewhere. Over at OnStartups, Jason Cohen suggests that instead of trying to figure out which strategy is best, given that conflicting ones have produced equally successful companies, perhaps you just need to buck conventional wisdom (and hence not copy 37signals or Fog Creek)... Thoughts?

The Dangers of Online Feedback

Business Week has a very interesting book excerpt from "What Would Google Do?" (Jeff Jarvis), titled "Detroit Should Get Cracking on its Googlemobile", which caught my eye, in part, because I'm currently reading Tom Vanderbilt's "Traffic: Why We Drive the Way We Do (and What it Says About Us)". Jarvis points out that at present auto manufacturers don't really communicate with their customers about what they would like, or allow them to customise their cars in any meaningful fashion. If they had, he argues, we would have had ways to interface our iPods with our car radios long ago. In the future, if they treated cars as a platform that allowed users to create their own cars, we might see unpainted cars being sold, then taken to local graffiti artists. All hail "open-source" (?!) cars, apparently, not to mention open-source urban planning.

That got me thinking. Many large corporations are today accused of not listening to their customers. Meanwhile many are trying to use the Internet to change that (take a look at Get Satisfaction). It used to be that to listen to your customers involved conducting telephone or paper surveys, or paying people to be in focus groups. Now you can just set-up an online forum, or blog about your ideas and see what comments come back. In many ways that's good: the cost of soliciting feedback is minimal, so even one-person startups can do it. The bad bit is that the company has to take the time to actually listen.

Whilst older companies have a reputation for not asking for feedback, it seems to me that the newer technology companies have a bad history of actually listening to feedback that concerns policy. That's distinct from feedback on software bugs, which are effectively win-win for the company and the consumer. Google, for example, is great at releasing its products in beta versions, and fixing them up in response to feedback. However, looking at the upset surrounding its retention of search logs, and it's the opposite. Similarly, Facebook's introduction of its Beacon technology, for publicising what purchases users had made, didn't really go down that well either, though they at least made the service an opt-in feature after about three weeks. (Any other examples?) The point is not that users aren't eventually listened to, but more that they're listened to quickly or completely only when the company considers it to be commercially sensible.

"So what?", you might ask, "Isn't that obvious?" Well, to a company, yes. Pandering to users whilst potentially cutting your revenue or effectiveness doesn't seem commercially sensible. But if consumers now expect this easy-feedback channel to be taken notice of, then when it's not, a revolt occurs. On the web, where the switching costs tend to be lower, customers might just decide to go elsewhere. Even with companies who produce more tangible products (cars, say), users can still make a fuss very publicly, and very quickly. Worse, they'll accuse the company of "not listening". Suddenly the feedback channel isn't so great any more. Particularly since a lot of that feedback is public for all the world to see.

So, as a small company, online feedback can be great for understanding how to shape something new. But it's perhaps important to manage users' expectations. Otherwise you might end up like Face Party, who closed shop for a while after users complained that they hadn't been given what they'd been promised. Moreover, dedicating time to making sure that the online feedback channel is tended to, so that you at least appear (!) as though you're listening will probably pay off.

Welcome to a brave new world, where goodwill is generated by listening, rather than another PR campaign. Oh, and where trying to fake reviews to gain goodwill will probably be discovered.