Friday, September 30, 2011

Rolling the Dice

I like GitHub. They make a really great product that is loved by almost every developer I've talked to who has used it. That is a worthy achievement.


Well, I read this post by Zach Holman about how GitHub has scaled their development process. It is well written by a guy who obviously loves his job, which means he's an performing as a real artisan.

Unfortunately, I think it would be highly unfortunate for any startup to take this as advice on how to do things at their company.

Building a startup is a fight against the odds. You are rolling the dice when you start. You are trying to get a saving throw, not bury your dice (OK, enough with the D&D!).

People work on what they want to work on. Product development is driven by whoever wants to drive product.

No. No, no, no, no. No.

That is the surest way to stack the dice against your startup. In this case, it may also become a prototypical case study in survivor bias (see my previous article discussing other types of logical fallacies in product development)).

GitHub is lucky that they are building a product that is tailored for developers. It means they get a saving throw. It is only a saving throw, though, because their developers, who are choosing what to work on, are only vaguely similar to their customers.

Think about this: GitHub is lucky their developers are similar to their customer (or at least their customer's influencer). The further these two points are from each other, the worse this advice becomes.

A startup needs somebody who understands how to find a market and drive a product that fits into that market. Whether this is the CEO or a product manager hired off the street doesn't matter, but they need somebody doing it who has the real authority to turn those learnings into a product for a market.

For what it's worth, I've lived the flip side of this coin: building a tool for developers driven by what we thought would be cool to build instead of having a product guy hitting the street to understand the real customer. After burning through a huge sum of money, the lights got turned off.

Building more barriers to product development is not the answer.

Neither is building features that confuse your market, cost you money to maintain, and, in general, don't advance your company's objectives.

I take my relationships with my developers very seriously. Developers who are treated as artisans create better products. I always strive to have relationships such that I am providing the why we are building it; the developers are I are going back and forth on the what to build; and the developers own the how to build it. That back and forth is crucial to building great products and is one of the best parts of my job.

But the answer to keeping the development pipeline open is not to just let developers build whatever tickles their fancy. The answer is to make sure you have enough bandwidth in product management to keep your developers stocked with features that are providing value to your customers and advancing your standing in your market.

If you want to do it right and get a +10 to all your die rolls, hire product management first.

OK, now I'm really done with the D&D stuff...

Photo credit: TomGazpacho

Thursday, September 22, 2011

Fallacious Product Management

One of the things I love about being a product manager is that it is much like being a scientist. Customer Development and Lean Startups are all about iterative experimentation, using data to understand your customers and to shape your product. While customer development and lean methodology are discussed a lot in the startup scene, the basic tenets involving hypotheses and experimenting apply just as well to product management at a company of any size.

If you think back to your elementary (primary) school science class, you'll remember that science is about finding truth, not about proving oneself correct. While easy to say, in practice, it can be very difficult and many scientists have been embarrassed as a result of not adhering to it.

Scientists and philosophers have spent countless years understanding how to make rational decisions. Knowing some of the common traps that lead us to make irrational conclusions is the first step.

Confirmation Bias

We sure do like to be right (in my house, it is called "being a Jensen" and my wife accuses me of it regularly!). We like being right so much, we unconsciously structure our lines of reasoning around the assumption we are right. In other words, we don't ask questions to prove ourselves wrong; instead, we ask questions to prove ourselves right.

In your product, this shows up as features nobody actually cares about that have data apparently showing how valuable they are. Unfortunately, the data didn't come from asking the right questions.

Are you asking questions to find the truth or to prove yourself right?

Appeals to Authority

Paul Graham said it was so. Or maybe it was Steve Jobs. No, it was Bill Gates. Wait, it was...well, it doesn't matter. When people are experts, it is worth listening to what they have to say about their field of expertise. The danger comes in listening to what they have to say about things they are not experts on and using that as a basis of your decision making (Yes, it's a fine line!).

In your product, this shows up as features added because an analyst or an investor or a VP thinks are cool.

Are you listing to experts instead of to your customers?

Misaligned Motivations

Whenever financial numbers are released in the news, it is fascinating to watch both political parties take the same information and claim how it proves their viewpoint is correct. Of course, reality is far more nuanced than that, but it illustrates an important point: we see what we are emotionally invested in seeing. The more emotionally tied we are to an idea, the more "evidence" we manage to dig up to support it.

In your product, this shows up as features that are added to support a set of customers that do not provide value to your product (the customers you should fire!).

Do you have an emotional connection that is clouding your vision?


If I asked who who was more likely to know whether a brain injury was caused by trauma, a neurosurgeon or her administrative assistant, you would probably say the surgeon. Certainly, the surgeons would. Turns out the administrative assistants were just as good as the surgeons at determining the cause of brain damage. Who do you think would be more likely to do research to find out the real cause?

In your product, this shows up as features being added based on your "deep" knowledge of the market with no quantitative or qualitative data to back them up.

Are you the neurosurgeon, completely sure you know the answers?


Which are you more likely to die from: an auto accident or a plane crash? We all know the answer is the four-wheeled death-mobiles called cars (using similarly fallacious logic, I tie risk to the number of wheels, so I ride a motorcycle: less wheels, less risk!). Yet how many people still make travel decisions based on the last catastrophe they heard about on the news? Plane crashes are rare, so they get news coverage; auto accidents are common, so they are ignored. People make decisions based on how familiar the data is, not on how valid the data is.

This is a particularly insidious trap, because you have to distinguish between things you are hearing a lot because they are important and things you are hearing a lot because people are talking about them!

In your product, this shows up as features being prioritized because "everybody talked about it at the last trade show" without any further market validation.

Are you digging to find the real needs that you wouldn't hear about otherwise?

Summing Up

As you can see, our brains are wired well for thinking poorly. It takes effort to overcome those ingrained thought processes, but the benefits of the effort are huge.

If you really want to dig in beyond these five and work on becoming a rationalist, you can dive into How the Mind Works or spend some time studying this fairly extensive list of fallacies.

What are fallacies you've found that negatively impact your product, your company, or yourself? What tools do you use to keep from making irrational decisions?

Wednesday, September 14, 2011

PMs and Startups: My PCamp Utah Presentation

I presented at ProductCamp Utah over the weekend. Maybe you will get some benefit out of it. If not, you should come to the next PCamp Utah where you'll get to learn from people smarter than me.

Tuesday, September 6, 2011

The Ultimate Product Manager

Steve Jobs stepped down as CEO of Apple. Nobody was surprised, yet everybody was still shocked. There has been and will continue to be a lot of commentary about his reign at Apple and his business savvy. Personally, I look at Jobs as the ultimate product manager, who came into his own long before the profession itself did.

As my tribute to him, I'd like to take a few of his quotes and discuss them from the product perspective. Afterwards, I'll sum up with a few thoughts of my own.

A lot of companies have chosen to downsize, and maybe that was the right thing for them. We chose a different path. Our belief was that if we kept putting great products in front of customers, they would continue to open their wallets.

As all great product managers know, you lead a company through great products. Once you start nickel and dining the product, while your accountants might love you next quarter, you have started down a path to mediocrity. Customers don't come in droves to a mediocre product. Steve practiced investing to gain returns, not quibbling about returns on investment.

We made the buttons on the screen look so good you’ll want to lick them.

Given all the demands Jobs has on his time, he still manages to focus on the details. Not just focused, but he sweats the details like no other person I've known of. And that, in turn, leads to lick-worthy buttons.

Apple's market share is bigger than BMW's or Mercedes's or Porsche's in the automotive market. What's wrong with being BMW or Mercedes?

You don't need to own the market. You don't even need a large percentage. If you are the best, you can command larger margins and thrive on a smaller piece of the pie while others race to the bottom..

For something this complicated, it’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.

When truly innovating, your customer can explain their pains and desires, but they won't be able to tell you the right solution. Instead, they will tell you to build a faster buggy. All product managers should have Jobs' empathy for his customers and the courage to fight to bring innovation to their customer. This applies to all products, not just highly complex ones.

[The iTunes music store] will go down in history as a turning point for the music industry. This is landmark stuff. I can’t overestimate it!

Jobs isn't afraid to go orthogonal to his products to add value. I'm sure he heard time and again, "Apple isn't a content company". Apple is still a software company that adds value through its hardware and the revenue content through iTunes brings is a very small percentage of Apple's revenue, yet the value it brings to Apple's product line is immeasurable. Maybe you need to become a content company to succeed.

I think if you do something and it turns out pretty good, then you should go do something else wonderful, not dwell on it for too long. Just figure out what’s next.

Doing it once isn't enough. Nor is resting on your laurels. Product managers need to one-up themselves as much as any competitor.

And now for my thoughts:

First, a major component of any success is luck. Jobs could have had an ordinary life. His fate was not pre-ordained. Instead, he just kept trying, giving himself more chances to succeed. Keep giving yourself chances and your ticket could come up, too. Stop trying to excel, and your future is certain! Edison, 10,000 ways not to make a light bulb and all that.

Second, he was not alone. He surrounded himself with other brilliant people, trained them in what he expected and let them do their jobs. Notwithstanding that, he owned the products. He gave the final approvals, he made sure everything was just right, he didn't let anything out the door until it was right.

Finally, Steve appreciated simplicity. So many products try to be all things to all people and wind up being nothing to anybody. The first iPhone was released without copy and paste functionality, a move pundits said would doom it. In fact, looking back, the first iPhone didn't do much of anything, yet what it did, it did very well.

And although I know he will never read this, I want to say thanks. Thanks for the great products (boy, did I want a NeXTcube!) but, moreover, thanks for showing us how to make great products. Good luck in your fight! I can't wait to see your next product.

Saturday, August 27, 2011

A Muggle, A Wizard, or a Product Manager?

Minister Fudge looks across the table at Professor Dumbledore. Even though the man has always made Fudge uncomfortable, he is still the most brilliant wizard Fudge knows.

"My days at the Ministry are numbered," Fudge says. "Given how messed up things are in the wizarding world, I'm thinking about going into business in the muggle world."

Dumbledore's eyes twinkle brightly as a smile plays across his lips. "Business in the muggle world is tough. How will you know you are selling what a muggle wants to buy?"

Fudge smirks. "I'm not the fool you think I am. I'm going to hire a muggle to tell me what muggles like."

Dumbledore nods sagely, eyes twinkling even more brightly behind his half-moon spectacles. "You are wise. But how will a muggle know what a wizard is capable of making? Seven years at Hogwarts gives a witch quit a range of skills that your muggle won't know about."

A look of panic crosses Fudge's face. "I hadn't thought of that! I guess I do need wizards telling me what I can make."

Dumbledore raises his bushy eyebrows. "I remember Harry Potter telling me about the first time his friend, Ron Weasely, called him on the muggle talking device called a telephone. While it was humorous to hear Harry tell the story of Ron generally making a fool of himself, his muggle uncle was far from pleased. I could tell you dozens of stories about our Muggle Studies class that would show you wizards really don't understand muggles."

Sweat breaks out on Fudge's brow, trickling into his eyes. "So I do need a muggle! I'll hire him immediately." Fudge looks at Dumbledore. Those damn twinkling eyes. I know he's laughing at me!

Dumbledore chuckles at Minister Fudges discomfort. "Minister, if you hire a muggle, you will have to bring him into our world to teach him what can be done. What happens after your muggle has been in the wizarding world for a while helping your wizards and witches?  They won't really be muggles anymore and certainly won't know about the muggle world anymore."

"So it's hopeless, isn't it?"

"No, Minister, it is not. What you need is a Product Manager!"

When you hire a professional product manager, you are hiring somebody who understands how to systematically bridge the gap between the market and the producers.

I've experienced many companies who have hired customers as product managers and found themselves with a person who understands the market today but doesn't understand how to keep up as the market changes over time. Invariably, these become dated, me-too products instead of market leaders as the "product managers" lead the product based on their out-of-date knowledge and what their competitors are doing.

I've also experienced companies who just throw an engineer into the roll because the product is "too technical" for a business guy. Neither the company nor the engineer are particularly interested in making sure she can accomplish the job (after all, it must be easier than the engineering work). These products tend to become technological monstrosities: Amazing features but no clear understanding of nor solution to the customers' pains. Features get added based on what gets voted for most with no clear product direction.

The key point here is that product management is a learned skill. People can move into the career, but they will need to be trained. If you are planning on hiring a junior member of a product management team to train, both of the above paths are completely valid. 

On the other hand, if you are looking for somebody to come in, understand your market, and direct your product to bigger and better things, you would be much better foregoing the muggles and wizards and choosing a product manager instead.

Monday, July 18, 2011

ProductCamp Utah

Well, it took us a little longer than we had hoped, but the Utah Product Management Association is putting on the first ProductCamp Utah on September 10th. Registration is now open.

All the details are here. Hope to see you there!

Saturday, July 9, 2011

Problem Solvers

How many times have you heard seem a product management job posting asking for years of experience in a particular field or, while talking to somebody about the position, been given the impression that only a certain type of person can succeed in the job.

I call BS!

Product management is not about any particular knowledge, though it can certainly help. Product management is really about solving problems, and when you are hiring product managers, you want a history of solving problems. Nothing will be more valuable to you because anything else can be learned. I've not had much success teaching problem solving; that seems much more innate.

Personally, I'm fascinated by failures. The way people recover from errors truly shows their problem solving abilities. When you are interviewing, follow trails of what went wrong and how they dealt with it. You'll get a much better perspective on their true personality and how much hand-holding you are going to have to do.

What about you? What tricks do you have for hiring great product managers?