Understanding Users
Paul Graham has a great article in “Startups in 13 Sentences:”
Having gotten it down to 13 sentences, I asked myself which I’d choose if I could only keep one.
Understand your users. That’s the key. The essential task in a startup is to create wealth; the dimension of wealth you have most control over is how much you improve users’ lives; and the hardest part of that is knowing what to make for them. Once you know what to make, it’s mere effort to make it, and most decent hackers are capable of that.
Then in “Geeks and Anti-Geeks,” Adam Barr writes:
You notice this if you listen to the chatter before a meeting. Half the time people are talking about World of Warcraft; those are the geeks. The other half they are talking about pinot noir; those are the anti-geeks. In either case, the group then proceeds to discuss a pattern-based approach to refactoring your C# class design in order to increase cohesion and leverage mock objects to achieve high code coverage while minimizing your unit test execution time.
…
The reason this matters is because Microsoft has recently been pushing engineers to realize that they are not the customer, the customers are not geeks, and therefore engineers can’t design properly for our customers. What I think happens, however, is that the anti-geeks hear this and think, “They’re not talking about me; I know that those beer-swilling geeks don’t understand the customer, but I’m a cultured sort, not a geek–I’m just like our customers!” And so they go out and design software for themselves…and of course they mess it up…because our customers may not spend their spare time playing Dungeons & Dragons, but neither do they spend it tramping across the Burgess Shale.
So I don’t disagree with Mr. Barr, but I do want to expand a little. The fundamental job of the program manager is to understand the market, come up with a solution that will delight the customer, sell that vision to the team, create and drive the product to shipping to those customers. The market only matters in understanding if a product is worth building, and in helping to shape our understanding of the customer by understanding their economic context.
I don’t think I’m anything like most of my customers. Those customers are first and foremost, 35,000 or so software engineers inside of Microsoft, second, security experts helping them or reviewing their work, and third, software engineers at other vendors who build on our platform. I’m most like the second set, but they’re a distant second, and (as several of them will tell you) I have a tendency to reject their first attempt at getting a feature out of hand, because our previous tools were so expert-centric.
More importantly, I don’t need to be like our customers to delight them. I am nothing like a professional chef, but I am frequently delighted by them. What I need to do is actively listen to those customers, and fairly and effectively advocate for their attitudes and words to my team.
As I was working on this Joel Spolsky posted “How to be a program manager,” which covers some similar ideas.
Seriously? In my twenty odd years of dealing with Microsoft and their products I have -never- gotten the impression that customers are first and foremost.
I recall an online discussion with the head of the group that came up with Windows logging mechanism. He came out and admitted that they designed the events to match what -we- (meaning the developers) wanted. That has always been the problem with Microsoft – you don’t design systems to meet customer requirements. You design them to meet Microsoft’s requirements.
Tim,
I am entirely serious when I say that enabling those customers is my #1 goal.
I think that Microsoft is at its best, and makes our best products, when we keep customers firmly in mind. Now, there’s often conflict. In my case, there’s expert vs normal software engineer conflict, and if you’re on the wrong side of that, you’re regularly annoyed with me.
Scaling that up to hundreds of millions of Windows and Office users, there’s obviously going to be different customer types to satisfy, and a need to make tradeoffs.
Products that meet only Microsoft requirements eventually go the way of Bob, because no one buys them.
I have met plenty of managers who consider their ignorance of the basic technology they are selling as making them more knowledgeable about customer requirements than the ‘geeks’ who do.
Fact is that being ignorant of the technology does not make you any wiser about your customer needs.
In many cases managers of this type believe in a type of customer that is non existent. Many years ago I watched great excitement as the company tried to deliver an outsourced provisioning ‘solution’ for the ‘enterprise’.
Now this was a perfectly reasonable product to sell during the dotcom boom. There were many startups who would have paid for a product that gave them a one stop shop that connected them to all the big company services – corporate credit cards, travel agency, 401K, healthcare and so on that their employees were used to and expected.
Only for some reason the idea was not to sell a $100/seat product to ten person startups, it was to outsource the HR departments are large F500 enterprises at a seven figure price point.
Actually the reason was pretty obvious. Making seven figure deals strokes the egos of executives even though every one of those deals will require customization that will end up causing a net loss. Enterprise sales make the marketing plan appear to work because all you need is four or five big sales each quarter. But lasting businesses are built over a course of years and are built one small sale at a time.
Does this then give an advantage to those of us who can happily converse about WoW raid strategies and which Michelin starred restaurants they’ve been too recently as well?
A foot in both worlds is not a bad thing. It’s why I like doing engineering management.
Does this then give an advantage to those of us who can happily converse about WoW raid strategies and which Michelin starred restaurants they’ve been too recently as well?
A foot in both worlds is not a bad thing. It’s why I like doing engineering management. Interpreting for both sides is actually a lot of fun.
Though I suppose I do self identify as a geek over non-geek. 🙂
The world outside Microsoft calls these people “product managers”, not “program managers”.
It’s quite true that most engineers, and practically all engineers in big organizations, don’t know, and what’s more don’t much care, about programming for the average end user. It takes extensive thought and care to avoid the many implicit assumptions that one typically makes that the user knows what you know, and that you know what the users are actually using each detail of the UI for, and the vast majority of engineers don’t take this thought and care.
Especially unfriendly is open source software — it is designed to be used by fellow engineers, whom the authors are trying to impress, not by average people.
This is why large organizations in particular need product/program managers, usability engineers, etc. And it’s just as important to talk to and try out prototype sofware with end users as it is to talk to customers (users and customers often aren’t the same people, especially when the customer is an organization).
Bob,
I’ve worked with great product managers–the first beat Geoff Moore’s positioning statement model into my head over a decade ago and I still use it. Program management is expected to do the project management roles and be in with the engineering team in a way that product managers are not.
Few tech companies outside of Microsoft even have positions called “program manager”, and even when they do it usually means somebody much more like a project manager than a product manager. Microsoft has its own unique terminology about these things: what you understand to be a “product manager” bears little relation to what other people understand by the term. Your post described tasks square in the center of the product manager’s role: understanding the relevant problems facing customers and users, understanding the available technology, and designing products using that technology to solve the users’ and customers’ problems. Product managers interact closely with architects, engineers, and prototypers as well as with customers and users. Marketing or “outbound” product managers are a different beast — those are the guys that write the marketing material for a product. Technical or “inbound” product managers sometimes also take on “outbound” marketing or project management tasks, but usually only as small companies that haven’t separated these roles. That’s the standard meaning of these terms in the tech industry — Microsoft, in this case, has not set any standard and is living in its own rain-shrouded bubble.
Bob,
I appreciate your feedback, and would ask–are you familiar with my bio? I have a 15 year career before Microsoft, including a few years consulting and a decade at four different startups. I really have never seen product management incorporate the gamut of things that Microsoft program managers are expected to do. Those additional functions include schedule management and a much deeper technical role than most product managers. Most product managers I’ve worked with deliver some form of “Market Requirements Document.” Most program managers will go to technical requirements, sometimes high level functional specs.
Please don’t believe that because I work for Microsoft, I’m in a rain-shrouded bubble, or that I think this is a standard.