Articles

Thanksgiving is my favorite holiday, and I’ve hosted for over 20 years. Turkey has always been the center of the dinner, but one year my husband said, “Let’s have ham this time.” 

Panic! How to cycle both through the limited oven space? Would smaller pans fit side-by-side? Can you microwave a ham? It took several days before we communicated clearly enough to resolve the problem. I assumed he meant ham and turkey. He meant ham, not turkey. We should have talked about it.

Assumptions are a problem for prioritization in product management, too. We talk with customers and colleagues to gather requirements and set a roadmap. Yes, you’ll get features A, B, and C. A few months later when D becomes essential — yes, we can make space and say yes to D. 

But were we explicit about what we’re removing from the roadmap to make space? After those productive brainstorming sessions … did we ever go back and say what isn’t in the plan? It’s not enough to talk up what’s planned and assume that our colleagues understand the remainder didn’t make it. We have to have the difficult conversation up front, so that we make the right decisions and set expectations correctly. We can do ham instead of turkey; are you OK with that tradeoff?

Everybody loves a Yes, but No is its essential companion because resources are always limited. 

A fast, clear No is a gift: it lets us understand what’s next, or choose to collaborate on creative workarounds. If it’s essential to have both ham and turkey, we can do the advanced planning to decide whether to buy a second oven, risk a deep fryer, or ask a friend to bake the ham. Or maybe we choose to make one dish really well. The key is intentional decision-making, based within the reality of what’s a true Yes… and what's a No.

I don't believe in the pursuit of an A+ average, whether in school or in life. I intentionally didn't aim for a 4.0, and I'm advising my daughter along the same path. Don't get me wrong: I absolutely value learning, creativity, and excellence, and sometimes that naturally results in a perfect score. But I worry that for most students, single-mindedly chasing a single measure of perfection misses the point of learning and diverts attention from goals that are equally important but less quantifiable. I think an "A-minus" is a better target: very good, but with some wiggle room. Twenty-five years in tech haven't persuaded me otherwise; I believe in passionate, imperfect adaptability out here in the working world, too.

But but but ... Don't you want your surgeon to have been an A+ student? Nope. Of course I want them to be excellent at anatomy and have wonderful hand-eye coordination. But other skills are just as important, and aren't what A+ medical students are always focused on learning.

• I want the surgeon to have emotional and cultural intelligence, so they know when I'm just pretending to understand how to care for my wound.

• I want the surgeon to understand how insurance works, so we can time a procedure for when I don't have to pay thousands out of pocket.

• I want the surgeon to have good social skills, so the nurse isn't afraid to say, "hey, wrong knee."

It's the same in software product management. Product Managers who are too focused on being The One who achieves a Perfect KPI score -- whether in growth, retention, or cost -- are likely to earn that A+ at a long-term cost... or fail to launch entirely.

The curse of the A+ student plays out in a variety of ways in product management and strategy:

• Risk avoidance. An A+ PM who's seeking perfection may play it too safe. They might not innovate fast or wildly enough, or might stick too long with what feels safe. Blockbuster Video avoided risk. An A- PM doesn't bet the company on every major launch, but knows market-testing some wacky ideas can pay off.

• Hiding mistakes. An A+ PM who's afraid to fail might try to fake metrics or capabilities. This did not work out for Theranos. An A- PM isn't embarrassed to admit mistakes -- and provides a safe space for colleagues to do the same.

• Inflexible vision. At the opposite end of the risk spectrum, an A+ PM can too easily over-value their own intelligence and miss the nuances that drive success. Google Glass was technologically amazing but freaked people out. An A- PM respects the complexity of the world and its inhabitants, and admits that even great ideas need to be refined.

• Analysis paralysis. An A+ PM who's afraid to make a mistake may agonize over validation and design so long they lose first mover advantage. Which products came to market later than they should have? Hard to know -- it's their companies' dirty secrets. An A- PM spends time on the risky elements, and trusts in iteration to get the details right.

• Dysfunctional relationships. An A+ PM who nails the metrics but has problematic interdepartmental relationships will have trouble repeating their success. Engineers will balk at the timelines and requirements, Customer Success will create shadow engineering, Sales will continue selling the tried-and-true. Success requires that everyone be along for the ride, and an A- PM has strong interpersonal and communication skills.

So, metaphorically speaking: study hard, but go to a few parties and try a pottery class, too. An A-minus attitude is more sustainable than pretending we're perfect, and it leaves space for adaptability and relationships. A broader view of achievement sets us up for genuine success.

In college, a literati-type friend made fun of the Agatha Christie novel I was reading. It wasn't art, it didn't have value. Pfft, I say. Twenty-mumble years later, I've still always got an old-fashioned murder mystery on my side table. Not only are they escapist entertainment (which is value enough), they also offer lessons and tactics I put to work at work. Four specific examples from my bookshelves...

Chief Inspector Armand Gamache (penned into life by Louise Penny) offers a caution in The Beautiful Mystery about assumptions:

"It was one of the first lessons he taught new recruits to his homicide division. Have no expectations. Enter every room, meet every man, woman and child, look at every body with an open mind. Not so open that their brains fell out, but open enough to see and hear the unexpected. Have no preconceptions. Murder was unexpected. And so often was the murderer."

The connection to user research and product design is obvious; the answer is so often surprising. But I see Quality lessons here, too. The source of a bug isn't always obvious and, although sometimes clear in retrospect, the vulnerabilities that bad actors can use may not be what you'd attempted to guard against. Skepticism and open eyes are good for the health of our products.

Lieutenant Jim Chee (of the Tony Hillerman mysteries) offers advice in The Fallen Man about research interviews:

"It was a tactic he'd used for years -- based on his theory that most humans prefer exchanging information to giving it away. ... Tell somebody something interesting and they'll try to top it. ... Let me tell you what I know, then you decide if you know anything you would be free to add that might be helpful."

Chee's looking for inside information about a case. But his tactics work equally well for market and user research. If all the questions go in one direction, your research subject will feel like they're being grilled by... well, by a detective. You'll get better results with a warm, natural conversation about the topic. To keep your results clean, you've got to be careful not to lead your witness with the answers you're hoping to get. But if you're getting feedback on a design, you can talk about how a previous design was improved by talking with users; or if you're gathering competitive intel, you can talk about an interesting but unrelated product. Two-way conversations are better than rapid-fire questions without context.

Miss Jane Marple (from who else but Agatha Christie) muses on human nature in The Thumbmark of St. Peter:

"Dash it all, Aunt Jane," said Raymond, "Don't spoil all the romance. Joyce and I aren't like the milkman and Annie." "That is where you make a mistake, dear," said Miss Marple. "Everybody is very much alike, really. But fortunately, perhaps, they don't realize it."

Miss Marple isn't a formal detective -- she's "just" an observant elderly resident of a small village. But she sees the same patterns of human behavior wherever she goes. Having worked in industries as disparate as Healthcare, Automotive, and Accounting, I've seen it too. The denizens of these industries don't realize it, but they share the same needs: consumable data insights, looking smart in front of their peers, fewer mouse clicks, responding to regulatory changes, demonstrable ROI. Smart PMs look for the industry-specific nuances but leverage the similarities.

Chief Inspector Gamache (reappearing because I adore him), in The Madness of Crowds, demonstrates the most important principle of all:

"But before Jean-Guy could speak, Armand said, "I'm sorry. You're right. Everything in your life now is about Idola and Honoré. I should have known that. Forgive me. I should never have put you in that position. It was wrong of me."

Gamache knows how to admit he is wrong. It's not a "I'm sorry you felt that way" apology; it's genuine. He sees his mistakes, admits them, and can move on. We work in a knowledge economy, and Being Right can feel so important. But everyone makes mistakes. We can only do great things, and with strong interpersonal relationships, if we're willing to call out our own missteps. Good teams do retrospectives; great teams fully embrace them. Good managers help their employees repair their faults; great managers admit that they have faults that need repairing, too.

I keep encountering a specific variation of the Specialist vs. Generalist debate, and I've evolved a strong stance. I call it the "Any Smart Developer" Fallacy, because I've repeatedly seen it create long-term problems for organizations.

At its heart is a generous and not even untrue assumption: that any smart developer can learn just about any aspect of software development. I've spent 25 years working closely with engineers and agree: they're capable and adaptable. However, if this observation hardens into an assumption that generalists are always better than specialists, chaos ensues.

At its most extreme, I've seen the fallacy lead to enterprise software organizations that lack testers, project managers, designers, data scientists, devops, and database admins. After all, any smart developer can handle those things, right?

Except that when you've got full stack developers trying to design the UI, write automated tests, evaluate kurtosis, maintain event logging, optimize indexes, and also manage priorities and communication ... something suffers. I've now seen four companies each spend years rewriting legacy internal systems and playing catch-up with testing to unwind the damage. Don't make this mistake. As soon as you've got budget to scale beyond three devs in a virtual garage, some of those folks should specialize in supporting your tech strategy.

High-quality, maintainable, well-designed, and well-understood software requires specialization. The "Any Smart Developer" Fallacy is just that ... an expensive fallacy.

The Agile/Scrum development process dictates engineer-led demos of each sprint's changes. In some organizations, only the devs and product folks attend; others make it a company-wide celebration of progress. As you might expect, when the whole gang's watching, they'll have more than just applause -- they'll also have questions and suggestions. 

As a product person, I like hearing the hot takes. What's surprising? What's confusing? What's missing? But a while back I noticed a pattern so consistent that I gave it a name: "Panda Bears."

The World Wildlife Foundation chose its panda logo wisely. The panda bear is adorable, and people love to spend time thinking about things that are appealing and easy to understand. The analogue in sprint demos is the user interface. Attendees love to focus on graphics, font, color, wording, and layout because the UI, like the panda, is easy and fun to talk about.

But what about the difficult, the complex, and the ugly? The blobfish deserves as much conservation attention as the panda. But somehow the blobfish and its ilk are rarely discussed in the sprint reviews. Careful UX design is important. But we also need to talk about details like security, performance, extensibility, quality, and logging at every sprint demo.

Some of you are now tuning out -- please don't. The products we build, sell, and support are complex and require the full attention of every employee. We won't make good decisions if the company-wide conversations focus on panda bears and only the tech folks talk about blobfish. Sales knows which performance issues affect deals. Marketing can estimate the impact of our competitor's latest security breach. Support is directly affected by how quickly we can track down account-specific oddities. We all benefit if we can reduce the time to market for that big new product launch. These topics are worthy of our time.

The blobfish isn't as accessibly adorable as the panda. Code maintainability is less fun to talk about than button placement. But it's not called a product ecosystem for nothing... the details are just as interconnected as the creatures of the world, and they all deserve our care and attention.

When a co-worker is overwhelmed, the kind thing to do is to pitch in. But how? It’s natural to ask what they need or provide a blanket offer: Let me know how I can help.

But that’s the opposite of helpful. Most people aren’t comfortable asking for favors. Or they’re so underwater, they don’t have the mental bandwidth to decide what to ask for.

My shorthand for this situation is to “offer to bring bagels for breakfast.” That may not literally be the solution, especially in our remote-work world, but metaphorically it suggests a concrete offer.

• Engineering’s underwater with bugs. Can the Product team delay or descope the next epic?

• Customer Success is struggling with rolling out a new feature. Want me to ride along for your next big visit?

• Marketing’s short-handed. Could a Product Manager take a first stab at drafting the press release?

When there’s a concrete suggestion on the table, your colleague might propose an alternative. Excellent — now you know how to help! The point of the “bagels” isn’t the details of the initial offer, it’s just a way to get you to a fruitful conversation. Just like when we’re testing a design concept with users, our colleagues are more willing to engage with a specific idea. Putting the effort in shows that you care.

Here’s to supporting each other in genuinely helpful ways.

I’ve sat through a lot of demos. Hundreds. Whoever’s showing their screen is zooming their mouse around, scrolling up and down, flipping between windows, talking while showing something complex, and all around going expert-level speed through material that is new to at least some participants. Half the time the text is so tiny it’s barely readable. At their worst, the demo-giver is also talking nonstop, until they ask at the very end: “Any questions?” Oh my goodness.

Slow down.

My kidding-not-kidding heuristic is to demo like the audience has already had three glasses of wine. Assume no prior knowledge, use no jargon. Assume everyone is multitasking (because they are, and that’s OK). Or they're crafting their own questions while you’re talking. Or they had a terrible morning and can barely focus. We’re all human. So pretend it’s a noisy, slightly scatterbrained dinner party with people you enjoy and want to communicate with.

Give the business context for each screen, and move slowly through it to make sure your audience is watching each time you move your mouse or show something new off. Be enthusiastic, but talk at an even pace. Introduce intentional spots for interim questions — as well as more casual pauses into which people can comfortably interrupt. When a question is asked, stop moving the mouse around and really listen to what’s asked, and then deliberately and slowly show the answer.

Most of all, don’t be afraid to repeat yourself. It’s OK to show the same screen or concept more than once. The audience will feel like they understand it better — and the reality is that half of them were multitasking the first time through anyway. Let them catch up. It doesn’t do any good “to get all the way through the material” if no one followed you. Show less, let the audience absorb it better. Frankly, you’ll enjoy your own demos more, too.