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...

The E-Myth Applied to Software Startups

In his book "The E-Myth", Michael Gerber asks why most small business don't work, and what to do about it. His main point is that people who go into business on their own tend to do so in order that they won't be working for someone else. Moreover, they tend to be the "worker" or "technician" type (not the manager, or strategist), who is good at creating the widgets/loaves of bread/furniture/other product. So they open a widget workshop/bakery/carpenter's workshop/other place as a one person venture.

So far so good. The new business probably works well, because the owner has enthusiasm and is skilled in what they do. However, the owner spends all of their waking hours attending to the work of producing the product. Gerber gives the example of a pie shop, where pies are baked early in the morning, sold throughout the day, and cleaning is done in the evening, all by the owner. The owner probably neglects areas of the business they don't know much about, such as book keeping. Neither do they get any time off. Crucially, they don't sit down and think where the business is heading (strategy).

Gerber argues that most of these people need to let their inner entrepreneur blossom. They need to own the business, rather than the technical work that goes into product manufacture. They do this by having a vision of the future of the company, and shaping the company to it, rather than shaping the future by what routine dictates. As they grow the company, they need to impart this vision to their new employees, and begin to make that vision a reality by taking on more of a managerial, and less of a technical, role. Part of this, Gerber, argues, involves documenting all the processes (e.g., how to make pies) that go on in the business, in order that the owner no longer has to check up on every step of production done by his/her employees. The result is a business that is easy to franchise.

Whilst this all makes sense for a business that produces something tangible, how can we apply it to software startups? Whilst not having a huge experience in this area, I thought I'd have a go at answering this question.

Firstly here are some of the differences I can see between the two situations:

• The capital cost of writing software is relatively small, unlike the initial investment required to rent a retail unit for a shop, or build a factory. This means that non-software businesses have to go and find funding, which normally means other people will take a look at their business plan before the business is set up. If you're spending life savings then it's different, but if you're writing software you're doing that too (just to keep food on the table)
• One doesn't tend to want to franchise software production. Outsource, possibly, and certainly bring new developers onboard. But the procedures that the startup uses won't be set in stone by the owner: they'll change as the company grows. What revision control system you use, or bug tracking software, or code format only needs to be specified at a later stage than what recipe is used for pies in a bakery.
• The cost of modifying software is very small. The cost of changing every widget that you have in stock because there's a flaw in it is at least linear in the number of widgets, so you'd better get it right first time. With software you can "plan to throw one away" (Fred Brooks; see my post The Mythical Man Month: Still Applicable Today).
• If a software product is intended for mass market, it's likely that its users will not understand how it works, and can't easily reverse engineer it to find out how. This is very different from most tangible products: most people understand vaguely how a pie is made, or have a mental model of how a car accelerates from standstill.
  

(I'm sure there are more: comment and let me know!)

I do think that technical people are as susceptible as any others when it comes to "working in their business rather than on it" (Gerber). But what exacerbates the issue is that software startups don't need initial cash, and hence owners aren't obliged to have anyone looking over their shoulders! Add to that the ease of (radically) changing their product, and suddenly the software startup is one where it's far more acceptable to have no real vision or idea of what you're doing. It's therefore very easy to waste time and then fold.

Software engineers are highly technical. In my experience, many dislike having to explain to a customer how a product works, and would hate to provide a dreaded technical support helpline. Instead, they argue that software can be made good enough that no support is needed, or those that do need support are evidently so lacking in intelligence that they don't deserve it. Yet this is crucial to getting the product sold to a mass market! Customer service is perhaps most needed in this business, and yet the software engineering stereotype is the worst-placed to provide it!

Linked to the previous point is the observation that performing market research is difficult. For a pie shop it's pretty easy: "Do you like apple pie, or would you prefer blackberry?" Software isn't as easily understood by the man on the street: "Would you like to buy my new super-fast sorting algorithm?" doesn't mean much. It requires the software engineer to divorce themselves from the beauty of the technology, and concentrate on its use by potential customers.

Another interesting issue with the low cost of modifying software is the speed at which new technologies (languages, tools, plug-in modules) become available. Unless a lone entrepreneur has a strong vision and will, it is very easy to frequently change to the newest technology, in the belief that this will create a better product. Of course, sometimes it does. But change has a time cost, which is much harder to quantify than the capital cost of buying a new piece of hardware, say.

Finally, as noted above, documentation of processes is far less important (in my opinion) for a software startup than for widget production. Gerber argues that documentation means practically anyone can read the "manual" and then achieve good results. I would argue that software is different in that it requires excellent people, as code quality can only be influenced by procedures to a small extent. In addition to good software engineers, there is a real need for one person with an overall view of what the aim and uses of the product are: they can then ensure that all the developers work in concert towards the vision of the company.

If You Get a Little Better at Sales, You'll Be Way Ahead of the Market

In my dealings with fellow Computer Scientists, I've noticed that many don't see the point of sales and marketing. Instead, they focus on technology. That is not to say that they are all totally unaware of sales/marketing, but if they do see the point, they see it as someone else's task, definitely not one for them to get involved in. In another excellent presentation from the Business of Software 2008 conference, Paul Kenny (of Ocean Learning) talks about how to be a better salesperson. Crucially, he dispels many of the myths that technical people hold about the role, addressing those in startups in particular. Here's the video, with my notes below it.

• If you have a bad opinion of salespeople, it's likely to be because you have experienced the "bad apples", rather than sales being a terrible thing in principle.
  
• Myths
  
• Products "sell themselves". (False, though great products can sell themselves to an extent.)
• Our customers "don't like being sold to". (Actually, they don't like being sold to badly!)
• Techies don't "get" sales people. (Not true! You sell to VCs, to your friends/family supporters, to your first employees.)
  
• How many of the people who, say, view your marketing video, call you for a demonstration? If it's only 5% (likely!) then you need a person to follow up: normally it's not something wrong with the product that stops someone buying it; it's other things getting in the way.
• The people who have the need for your product are probably not the people with the money. You need a salesperson to go and talk to the people higher up, to make them feel the need.
• Talk about specific uses/users, not the science/how the product works. If you can convince your buyer that a user they know personally will benefit from it, that is a powerful sell.
• Users have "needs behind needs". People will tell you that the reason they buy an SUV is because they like the 4WD or stability. In practice they actually like SUVs because they make their families safer when driving, or for the feeling they get when they are able to look down on other drivers.
• Be prepared to go one-to-one with customers to understand their particular situations and what features they will use.
• Sales are very dependent on the emotional impact of your product. You need to position your product in people's minds. Trade-off between perceived cost and perceived value. Note that it's perception that matters, which can be managed by a salesperson.
• If you want a salesperson, don't recruit a stereotype! Start with what you need them to do: fast response (cheap product), or in-depth service (expensive product, high risk for client). They require different skills.
• What is your company culture? Will the salesperson you are recruiting exude that culture? Don't stitch customers up.
  
• Don't worry about admitting that your product isn't suitable for a customer's needs; they will remember you, as you'll probably be the first person who was honest with them in that way.
• Don't hire experience, hire attitude first (then experience!). You can't train attitude into someone. If a candidate hasn't researched your company much at all, or is lax in some things, don't hire them: they will be the same about your customers.
• Skills: self-starting/self-motivated, intelligent in questioning/listening, sounds/looks like they mean it, can deal with resistance, persistent.
• Sales take huge amounts of energy: have a dedicated person, rather than combining with other jobs. If you can, have more than one salesperson to spread the load, and motivate each other.
• If you have no dedicated person, and all of you in the company do some sales, come together and do it at the same time.
  
• Don't just reward deals: that will result in salespeople who don't care about the customer. Instead, reward contact with customers, and show interest in those skills.
• Sales can be boring: how can you vary your salesperson's job, on a regular basis?
• Train your salespeople regularly. They will go off the boil otherwise.
• For high-value salespeople, bonus them over 6-12 months, as such sales take a long time. Low value sales are different, probably bonus over short term.
  

Ultimately, show your salespeople that they are hugely important to you, motivate them, and ensure that they develop relationships with customers.