• Use the product extensively
• Get to know the customers deeply
• Internalize the company’s strategy and goals
• Learn your team’s methods and values
• Find out who the influencers are in the company
• Find a quick win for the team

The critical addition often missing is this:

• Sit down with someone in Finance and understand how money works in the business

If you’re at a startup, you might talk to the CFO. At a larger company, maybe you talk to someone who reports to the CFO. Below are some questions to ask and at the bottom of the post, I also have advice specific to CPOs/product heads starting a job.

Questions to consider asking:

• What are the most important parts of the income statement to our business?
• What are our financial strengths and weaknesses?
• Are there important aspects to know either about our cash flows or how we use our balance sheet?
• What are the one or two metrics you watch most carefully around revenue?
• Are there aspects to either our gross or operating margin that we are actively trying to change?
• What else about the financials of this company do you wish all product managers here knew?

And of course, don’t be afraid to ask a follow-on question if you don’t understand their answer.

Why do this?

I bet just by reading those questions you already know why it’s important to do this: you’ll have a much deeper understanding of the business model, the company’s state, strategy, and goals. You’ll be able to think about prioritization in a much more sophisticated way. And you’ll show the organization that you think like a business leader.

But what if my culture is tight about financial details?

Most leaders in Finance are thrilled to have a product manager ask to learn more about the finances of the business. Very few people, in any part of the organization, do this! However, some companies can be tight about their finances. If that is your culture, it won’t hurt to have your head of product ask on your behalf. Then Finance will be more likely to give you time and also open up in answering questions. And if your head of product steers you away from Finance, then ask the above questions to your head of product! Ideally they know the answers too.

Advice for new CPOs / Heads of Product

If you are a new head of product, all of the above applies. Your CFO is going to be thrilled to have a partner who takes a keen interest in the financials. Kicking off your relationship with evidence that you make finance a priority — well it’s just a good look, not to mention will make you better at your job. You’ll be glad to have that mutual trust with the CFO when it comes to future asks around incentive systems, spending, growth ideas, or even, sadly, navigating a restructuring.

My recommendation is to go beyond conversation. Once you understand the business, get cozy with a spreadsheet and model out your understanding of the product’s full “business model”: how prospects flow in, convert to customers/users, expand in revenue or churn, etc. You want to map out the important parts of your system. When you hit gaps in your knowledge, go get the answers.

I’d recommend one of two approaches: 1. create a 3 month snapshot if you’re trying to understand the mechanisms of the business; or 2. create a model that goes back 12 months and forward 12 months if you’re trying to understand how things are trending.

Do not start with a template — that’s just going to push you into generic FP&A (financial planning and analysis) territory that is too high level — useful to finance and the board but not to you as product leader. Again, this exercise is about creating a blueprint of the system that is the business, with the product anchored in the center. It’s about understanding your logic flows and conversion rates. Start either with a blank sheet of paper or a blank spreadsheet.

Once you have a decent draft, sit down with your CFO and walk through the model, making sure they know it is: 1) a draft, and 2) just a tool you are using to better understand the business, not something you expect Finance to use.

Two things are likely to happen. First, the CFO will help you sharpen the model, thus improving your understanding of the business. Second, you are likely to help the CFO better understand the business too! CFOs are not product people and often don’t have a detailed understanding of how product activity connects to financial outcomes. However, every CFO I’ve ever worked with is interested in this. They all want to think and help the business strategically.

It’s time consuming to do this, but I can’t think of better homework to understand your business, refine your thinking about impact and priorities, and build a great partnership with your CFO.

p.s. if you’re a product manager reading this section, not a product leader, why not turn this is into a group exercise for the PM team? can you make a model of the system that is your product’s business model?

There are many strategy frameworks out there. I believe in using many, not one — 7 powers, porter, Gib Biddle’s DHM/GEM. But one of the most interesting questions you should ask is: “What are the big points of decision tension in our business?” Examples might be: buyers vs sellers. Install base vs new. Innovation vs tech debt. Consumer vs enterprise.

Calling out these questions helps you spot where strategy is under-baked. If the answer is always “both or it depends”, you’re putting a huge amount of decision-making overhead onto the organization. You need what I call “key decision-making principles”.

An example: one example I’ve pointed to a few times is how Meetup was struggling to understand where and how to prioritize the demand-side (attendees) versus the supply-side (organizers). Organizers were (and are) the paying customer, yet if you really had to think about the two sides and in the process examined Meetup’s strengths and weaknesses as well as the competitive landscape, you realized that Meetup’s best chances were to remain what Ben Thompson calls an “aggregator” marketplace (Airbnb is another example of an aggregator marketplace — their strength is in aggregating demand). In my eyes at the time, Eventbrite was winning as a “platform” marketplace. We needed to be on a different playing field, at least as much as we could. While Meetup had to make both sides of its market successful, this simple insight/conclusion helped cut through so many debates.

Spotting these areas of tension tells you where to focus. It tells you where you need greater clarity on when and why you would choose one versus the other, and in getting to that greater clarity, you’re usually able to uncover deep, root-level strategic principles that should drive your business. Sometimes it shows you need more clarity on where you are going. However, most often, you need more clarity on what you *are* and *are not*.

People like optionality and are afraid of making the wrong call (understandably!), so it’s painful to define the *are not* side, but needed.

Good strategy helps you say no to things. Focus your strategic thinking on where you are struggling to know whether to say yes or no — where “both” seems to be the answer, but you know it can’t really be both.

Then force yourself to clarity around these key decision-making principles.

In April 2020, I stepped away from leading product and engineering at Meetup. The company was just getting spun out of WeWork and my kids were going through difficult times. They needed more time than either my, nor my wife’s, high-intensity jobs would support. The choice to focus on family was well worth it and both kids are now doing well. But I admit, I missed being an operator. I did some writing (Becoming Monday), teaching (NYU Stern), and consulting, but it’s just not the same as having a team and building a company. However, I didn’t think my ongoing family needs would allow me to do that. Growth-stage and startup exec jobs aren’t known for supporting “balance”.

A few weeks ago, I caught up with an old friend, Andres Glusman, to hear the latest about his startup DoWhatWorks. Andres, Kareem Kouddous and I ran the Lean Startup Meetup in New York for years. We shared a passion for scrappy experimentation and evidence-based thinking. Andres was a longtime exec at Meetup, at various times running growth, product, and strategy. He actually introduced me to the new Meetup CEO as he was leaving, which is why I ended up there in the first place.

Andres updated me on how far DoWhatWorks had come and I was really impressed. They have an amazing initial roster of paying customers, great retention, and a really interesting product — what Dres calls a “conversion rate accelerator”.

DoWhatWorks built an engine that scours the Web for growth experiments being run, by which I mean landing pages, pricing pages, incentive programs, sign-up flows, e-commerce purchase moments, product description pages, even search advertising. In other words, all the things we do to get someone to sign up or buy our products. They not only detect experiments, they also spot the winners and losers of those experiments. DoWhatWorks customers subscribe to access those insights.

I don’t know about you, but I’ve had to design all of those things, and I’ve hated the guesswork. These pages and programs are directly connected to revenue, and yet in the past it always felt like we had a hand tied behind our backs. We had the bandwidth to run some experiments optimizing our funnel, but we still had to make a huge number of decisions based purely on anecdotal evidence.

We would say, “We can’t A/B test everything, so let’s go look at how Airbnb does it. They know what they’re doing, right?” But that approach was never good enough. It’s just what we had to live with, until now.

DoWhatWorks opens up a whole new body of evidence. To me, it’s like being handed a cheat code to race ahead in the game.

I told Dres that I wished the growth and marketing teams at my previous companies had something like his product at their fingertips. Then he changed the topic: “Join us and help build the company,” he said. “We can do this in a way that protects your need to give time to family.”

I’ll be honest — this felt a bit revelatory to me. Here was a startup that wanted me to carve out time for family. Dres said he was going to hold me accountable to making sure I did that. Because, knowing me so well, he knew that I’m a huge part of the problem: I’m obsessive. I get invested in something and then I go all-in. And because of our long relationship, I believed him.

So here I am, building a company and product that I believe in, AND working with a partner who understands that I have to drive my kids to and from school, help them with their homework, make sure that our family is having dinner together. I really hadn’t believed that this “AND” was possible until it came from Dres.

I’ll also admit that I really love being back at the early stage. I get to wear all the hats again! In the course of a day, I’m doing some sales, some marketing, some product, some customer success, and more. I love flexing all of those muscles. They all intersect and help a young company become more customer-centric and move faster. We’ve made my title “Partner” because it more accurately reflects that I’m working across the board, not just taking a particular swim lane. That will evolve as we grow the team, but that’s how you need to be at the early stage.

Here’s another fun part of this job. The prospects and customers I get to talk to each day? They are our people! Product, growth, marketing people who care about evidence and outcomes. Teams who want to be on the cutting edge of product-led growth. Teams that care about building a culture of smart experimentation.

I have the advantage after so many years doing startups of working smarter, rather than harder. Still, I’m having to fight myself to keep balance. To keep that obsessive part of my nature at bay.

So here I am. Back in startupland and loving it. If you’re wrestling with the kind of growth and conversion challenges I mentioned above, I’d love to talk. My email is giff@dowhatworks.io.

Top image by Jordan Wozniak on Unsplash

The challenge for entrepreneurs is that Andrew’s good advice contradicts much of what they see and hear.

“Do things that don’t scale”
“Growth takes care of the rest”
“Get yourself the funding and thus the runway to fix your problems”
“Fake it till you make it.”

Also confusing the waters: founders see other startups out there who have raised a lot of money while patching over churn problems through customer success, hype, and VC-fueled momentum. These distortions are made worse by how attention works in startupland — we talk/hear about the companies when they appear to be doing well, but once they stumble they turn invisible.

Case in point: I was once with a company that grew nicely right through their series-C by diversifying into new customer sector after customer sector, until they ran out of new sectors. Then their churn problems ate them alive and there was no more VC lifeline to keep the wheels turning. I can attest to the fact that it’s brutal fixing these problems at 100, 200, 300 people rather than at 20.

Another trouble for founders is that too few investors, outside of the pre-seed set, really care about product. These mid-to-later stage investors care about growth and are obsessed with distribution (sales and marketing). You can understand why — they’re expecting their money to be used to scale. That’s what they were pitched to win their money. Those pesky product and business model problems were supposed to be solved in the earlier stage. The company has product-market fit, right?! Unfortunately, too often those problems are, indeed, patched over. When the truth becomes impossible to avoid, tensions at the top become even uglier because of the mismatch of investor expectations and the realities of the company.

The Problem with “Product-Market Fit”

The phrase product-market fit is used everywhere, at companies large and small. Most people treat it like a line in the sand: we are pre-PMF or post-PMF. That’s not really how things work. Target markets are really made up of many niche customer segments. The adoption curve for companies is really made up of many smaller adoption curves. I try to teach aspiring product managers that every new feature, let alone new product, has an adoption curve.

When founders think of product market fit as a “pre and post” concept, they have to convince themselves that they are post, or very near post. If they can’t convince themselves, how can they ever convince investors to give them money? The answer is: they can’t. So all the incentives and pressure in the system points to papering over the issues and getting that growth.

It doesn’t matter how good Andrew’s advice is when most people fall prey to the incentives of the system.

Sean Ellis’ Universally Ignored Advice

The very best advice about startup growth that I’ve ever read comes from one of the fathers of growth hacking, Sean Ellis (also the man who created the useful “very disappointed” survey). Sean argued that startups should first make sure that the product (and I’ll add, revenue model) is working. Customers are seeing value. Retention is looking good and sustainable. At this point (and earlier) most startups want to pour on the gas, but Sean says hold on! Now take several months and fix your top-of-funnel. You’ve probably got a very leaky bucket. Improve those conversion rates and optimize that first user experience (phase 2). Once that is done, now pour on the gas (phase 3).

Almost no one does this. People skip over phase 2, or to Andrew’s point, even skip over phase 1. There is simply too much pressure in the VC ecosystem to grow. There is seemingly plenty of evidence that growth begets growth but again there’s a catch. VCs really only need, and expect, 2 in 20 startups to succeed. They have a portfolio. You, as founder or exec, have a single shot. You’re committed. But what is prudent usually falls prey to growth pressure in startupland. Investors protest and say comments like this are unfair. “We’re not telling our CEOs what to do!” But I think it’s exactly the incentives of the VC system that fuels this.

So what to do?

If you are lucky enough to be one of those companies that is seeing phenomenal growth and retention, don’t change a thing. Keep on rocking out — keeping up with that kind of growth is a challenge unto itself. But that’s a single-digit percentage of startups. My advice for the others, equally as hard to follow as Andrew’s advice, is to use restraint.

If your business hasn’t yet clicked into a truly working system, don’t try to scale. Note that I didn’t say don’t ship, I said don’t yet try to scale. Focus on product value, revenue model, and enough of a repeatable customer acquisition process that your business becomes economically sustainable or at least your runway is bearable. Learn aggressively outside of your walls (virtual or otherwise). Pay more attention to your revenue model than your thought you needed to — is it helping or hurting your flywheel? In many cases, you’ll also need to narrow your target customer segments, while keeping an eye on the bigger market. Do not raise venture capital money to solve your traction/retention problem. Don’t even try, because all that energy will take away from what you really need to solve.

Throughout this phase, you need to remind yourself that the Traction Treadmill is a mirage — trading short terms wins for medium term pain. Avoid the temptation of hail mary plays that might land you that next batch of funding and buy you the time to solve these problems — that’s also a high-risk mirage.

Don’t get me wrong. I know people who have pulled this off, but it’s going all-in on a pair of fives.

I’m keenly aware that my advice is an absolute bitch to follow, because it requires money and therein lies the nasty, horrible, catch-22 of startups. It’s why I swore to myself after my last startup that I wasn’t founding another unless I had saved up 2 years of personal runway — the ability to go for a full 2 years before needing to raise capital. Which is, of course, exceedingly difficult to do. Impossible for many if not most. Certainly impossible for me right now with a family.

So we end up right where we began. Founders think, “I’m already taking on risk, so what’s a little more. Go for the growth, sell that vision, raise the capital, and then pull that rabbit out of the hat. Andrew’s right, but I can’t afford his advice. Others have done it, why can’t I? Hell, look at so-and-so. They’re famous now!”

It’s alluring. But the trade often leads to more pain down the road. Early stage comes with pain, but deeper pain comes later when you have employees and investors and customers counting on you, and your business starts to stumble. When the reality of fake-it-till-you-make-it starts to come home to roost. The layoffs begin and you can see the feelings of betrayal in your employees’ eyes. You harden your mind and heart just to survive to emotions of it all, but that’s just a delaying tactic. The toll will hit sooner or later. And you have to suffer the realization that you have invested so many years of life, sacrificed so much due to excessively long hours, just to get a shot at reaching the sun, only to have it snatched away.

Young founders don’t want to hear this stuff. “That won’t be me,” they think. “Our idea is hot, our team is great, we’re going to be one of the ones that make it.” It doesn’t matter how many people preach a more restrained approach. More and more of us veterans are saying, “Only go-big-or-go-home startups should raise venture capital. The majority should not.” New founders don’t want to hear it. Often, they can’t because, honestly, they need the capital. Their option isn’t what kind of startup should I do, but rather, can I do a startup at all?

But the truth is that Andrew is right. Sean Ellis is right. So the question to most founders is this: are you able to buck the incentives, resist the screwed up nature of startup mythology and optics, and do the smart thing?

By the way, Andrew Chen has a new book coming out that you can be sure I’m going to read: The Cold Start Problem.

Top image by Ben Welch on Unsplash

1. Make software a continuous process

The rate at which the Earth moves around the sun shouldn’t control your software project. Months, quarters, years — these are useful constructs for planning, goal setting, and setting expectations, but the work is the work. We all know that it’s hard, complex, and inherently unpredictable; not just the coding part, but even more so the delivering value part. So the best way to handle this is to turn our work into a continuous process — continuous improvement of ourselves, continuous delivery of value to customers, and continuous evolution of our strategy.

I’ve experimented with multi-week sprints/iterations and not having sprints at all, and I’ve found 1 week to be the most effective structure. You start the week re-aligning, you work the week, you evaluate how you are doing, you take as much of the weekend off as you can, and then you get back to it.

Anything longer than a week and people start to confuse the sprint length with “shipping something” length. Those two should be completely disconnected. Sometimes you can ship something in two hours. Sometimes in 5 weeks. When your agile sprint becomes about shipping something, you end up in one of two modes: either work expands to fill the time (unproductive) or you end up in crunch mode desperately trying to get something done (recipe for burnout).

Both are bad. Instead, we need to strive for sustainable intensity. Finding that balance is hard — it requires a leader who models it, and it requires a team who demands it of each other. It’s easy for a team to slip down to the lowest common denominator — i.e. the pace of the least intense person on the team. That’s not something to be proud of, it’s not how you win in the market, and it’s an invitation for top-down, deadline-oriented control to re-assert itself.

Btw, credit where credit is due: thanks to my former colleagues Jeff Gothelf and Josh Seiden for putting the word “continuous” in my lexicon. It’s the right word.

2. Always have a team leader

At Neo (now Pivotal), my colleagues and I ran experiments to see how flat we could make teams. Surely, we thought, if you get a bunch of smart, motivated people together with a shared goal, they can figure out the rest for themselves. Turns out, not so much. The kicker is hard decisions. Not everyone likes ‘em. People avoid them, delay them, or get bogged down in debate over them. It’s remarkably helpful to have one person looking at the big picture and making sure the team is making decisions intelligently and quickly (both are equally important). And to be brutally honest, it helps to have someone feeling responsible for modeling “sustainable intensity” in order to avoid the lowest common denominator problem I mentioned above.

The leader does not have to come from any particular discipline, however they do need a few attributes. They need to feel a personal sense of responsibility for the success of the team (both output and outcomes). They need to foster a true sense of partnership and communication across the team. Ideally they help shape the narrative (the story and optics) of the team across the company and executives. They ensure — through clarity and repetition — that everyone understands the goals of the team and the reasons behind those goals. They need to have the backbone to ensure that hard decisions get made (regardless of who makes the decision — it doesn’t have to be them). They need to have enough experience to have good judgement. Lastly and just as important, they need to have the soft skills to inspire, help, empower, include, push yet not alienate, the team drive to that success.

What is a good leader? My favorite definition comes from Francis Frei and Anne Morriss’ book Unleashed: “Leadership is about making others better, first as a result of our presence, and then in such a way that it lasts into our absence.”

3. Build strong triads

At the core of a great software team is a great partnership between the PM, the lead designer, and the lead engineer. There’s been a lot written about this so I’ll be brief, but I did want to shout out my firm approval of the triad concept. They should be talking all the time, both informally and with their own meetings in addition to the all-team meetings — usually as prep for those. They should be totally aligned. They should know each other’s business and be able to pitch in for each other, even if imperfectly, if someone is overwhelmed or on vacation. To state the obvious, this means the lead engineer is not coding all the time, not even the majority of their time.

4. Look through and past the frameworks

Every single process methodology out there gets ruined in human hands. Agile. Lean. Design Thinking. Doesn’t matter. Sometimes they get co-opted in a subversive way to fit an alternate agenda (exhibit A: SAFe). Sometimes just misunderstood (“MVP”). The best approach is to remember the original context of the framework (agile was created in an engineering service delivery context), to look past the tactics to the useful underlying principles, and make them your own. In doing so, you will make mistakes like the rest of us, but from there you can learn and iterate.

My own approach is to set guardrails and then let teams diverge from there. To say, “here is our baseline of what good looks like — we recommend working this particular way (XYZ).” It provides reasonable team autonomy without creating a situation where a bunch of people are fumbling around in the dark.

It’s very useful to treat everything as an experiment, including how we work. That creates the space for continuous improvement, which can only happen through experimentation.

I remember at Meetup, Yvette Pasqua (CTO at the time) and I (CPO at the time) had a few teams that wanted to try mobbing. Mobbing is where a whole bunch of engineers tackle a coding problem together in real-time (as opposed to pairing or a single engineer working the problem and getting code review later). From the outside, it looks terribly wasteful. Indeed, we got some comments from non-tech execs wondering what was going on. But we were open to letting the teams try it out, and concluded that yes, there were times that mobbing could be tremendously helpful, especially around big coding decisions with downstream implications. There were also times when mobbing was not helpful and we expected the teams to know when to use it and when not to (“fun” was not the criteria). Our job as leaders was to create the environment where: 1) experimentation could happen; 2) experimentation led to actual insights and conclusions; 3) the experimenting teams had an obligation to share those insights with the rest of our teams.

5. Design an interruption culture (within reason)

This sounds weird, but once a team has code quality under control, the next-most unproductive setbacks often come from software engineers not asking questions as they implement a story. How does this play out? The PM and lead engineer write out the user stories as thoughtfully as they can, but something is missed. The engineer gets to a point in their implementation and thinks, “huh, did they mean X or Y?” Now if the engineer is like most engineers, they are chasing a flow state. The last thing they want to do is break out of flow to go talk to someone. It feels tremendously unproductive because it is!

Not interrupting flow solves a small productivity problem at the expense of creating a very big one. Quite often, when the engineer chooses X over Y, they’ve made an erroneous assumption which is now baked into code. It might get caught soonish, it might not. The rework is far, far more expensive than the break in flow.

The way to solve this is to convince the engineering team that they have to stop and ask the question. Be patient — this is a hard habit to build. You also have to make this easy to do. The PM, designer, and engineering lead should know every user story intimately. This means that the engineer has THREE people to hit up on chat, phone, video, a tap on the shoulder, etc. Don’t create a dependency on the PM. Do make sure that those three are highly responsive. If the engineers have to wait, if they are bottlenecked, they will stop asking and instead will go back to making assumptions.

6. Simplify the tools

In many ways, the agile community at large has ignored the very first tenet of the agile manifesto: “Individuals and interactions over processes and tools.” That’s why I’ve found it helpful to have a mindset of minimal viable everything: what’s the least amount of process and tooling that lets a team flow, without having too little.

I do believe in things like weekly planning/alignment meetings and I do think regular retrospectives are excellent for team health (as long as they are an honest, blunt, yet safe space). My biggest annoyance tends to come with tooling.

Call me old fashioned, but I believe that PMs should write, or co-write, developer stories. I think a big part of the PM job is bridging the strategy/customer worlds and the engineering worlds. You can’t do that if you’ve lost touch with the details on either side. That said, the PM only has to concern themselves with the details of what something is and why it should exist, not how it is implemented in code.

You need to prevent lower-level engineering tasks from overwhelming and confusing the higher level “what/why” tasks. Historically, this is why I’ve hated Jira — everything spins out into it’s own card, flooding the backlog. I prefer tools where the implementation todos stay neatly on the story card itself. Whatever tool you use, aim for minimum viable simplicity to improve the flow state of the team and keep people focused on what really matters: why something is being built!

7. Create escalation paths

While executives need to know who owns final decision-making power, I actually don’t love the idea that product teams have “final decider” roles for different issues. The members of the team should respect each others’ expertise, but there are times when someone is really concerned about a decision. A designer should be able to object to an engineering decision and vice versa.

Don’t put it to a vote. If it’s important enough, escalate it to someone above the team. Pull in a VP. If you have good VPs, it shouldn’t matter whether you pull in a PM, design, or engineering VP. They should know that their job isn’t to make the decision for the team, nor to back the opinion of whoever is in their function, but rather to ask the right questions of the team and help shape the higher level strategic or operational contexts so that the best (or least worst) decision becomes clear.

I’ve seen this work wonders for increasing the feeling of partnership on a team, yet also respecting the very useful right for an individual to pull the andon cord.

As a leader, the only way to seed this is to get buy-in across the PM, design and eng leadership, to create a safe space for escalation. Yes! It’s ok to disagree with your teammates, it’s ok to reach outside of the team for help. It’s not just OK, it’s expected of you! You need to repeatedly communicate this to the teams. You also need to train the VP level to know how to handle an escalation. One bad experience with a bossy or biased VP and the team won’t trust the process again.

8. For new teams, create a working agreement

There’s nothing like working on a team that just flows. Everyone is aligned around the what and the why, people can debate ideas safely yet respectfully, everyone is good at their jobs and can be counted on to deliver. When you get these conditions right, you can just fly. And it feels great.

It takes time to get into this state. A useful crutch to speed this along is to create a team working agreement. This is a living document (i.e. can be updated at any time) that everyone signs off on. It takes unspoken assumptions and gets them out in the open to be discussed, debated, and aligned around. Useful things to include: what are our working methods (weekly iterations? TDD? code review process? etc); what are our overlapped working hours (critical for distributed teams); and anything else that is important for spelling out what “good” looks like. But remember “minimum viable everything” — keep the doc as simple and clear as you can, and don’t let perfect be the enemy of good. Ship something together, and iterate as needed.

9. Don’t ask for permission — bake the right things to do into your work

There’s a laundry list of “best practice” working methods that many teams want to do and yet don’t seem to get executive permission to do: research, experiments, analytics instrumentation, A/B testing and tracking, internationalization, writing tests, and iteration.

Boy that list is depressingly long, isn’t it?

My basic recommendation is to not ask permission to do the work the way the team knows the work should be done, especially if you can keep the time investment efficient and reasonable. Of course, you can’t be in outright revolt, but a lot of teams can do more than they think.

For example, bake analytics or internationalization right into your stories. Don’t make them a later phase or a separate bunch of stories that can be punted to the icebox. Make writing good software tests (whether TDD or another approach) simply part of the process of writing code. You don’t ask permission for a sprint planning meeting, do you? So why do it for this other, also necessary, stuff?

Iterating a feature release, however, is one area where you do need executive support and cover, because the space for iteration needs to be created on the roadmap.

10. Build autonomy through earned trust and communication

Most reasonable people accept that, in the ideal, it’s a good idea to give a team a goal and the autonomy to figure out how to hit the goal. So why doesn’t it happen? The answer is simply trust. Leadership doesn’t trust the teams to make the best decisions. They’ve seen teams get in their own way, or chase their own agendas instead of the company goals, or any other myriad of mistakes. Sadly, the alternative — executive control — rarely delivers good outcomes either because the execs aren’t close enough to the data and feedback loops.

To get to autonomous teams, it takes two to tango. Leadership must be clear about strategy and goals. And the team has to not just respect the guardrails put in place by leadership, but constantly communicate, constantly check-in: “Are we still aligned?”; “Hey, you should know about these challenges.”; “Here’s our progress and confidence in hitting the goals we set.” etc etc. (see an OKR structure I like to use)

Some execs get confused between A) a team learning how to execute well and work together with B) a team ready to handle local decision-making autonomy. You can grant the latter while leaning in to coach the former.

By the way, the communication I speak of isn’t just something teams have to do for their execs. As a CPO, you are constantly checking in on, and reinforcing, alignment with the CEO and other execs. In a company, no one should run solo for a long time. So remember that communication is not a sign of lack of trust. It is a necessary way to build and reinforce trust. Don’t be a black box or you could lose the autonomy you worked so hard to gain.

Final Word

Of course there’s a mountain of other important topics when it comes to making software, but I hope the above list might be useful food for thought for your team.

Top image by Fabio Henning on Unsplash

I’ve been pushing my students to narrow their customer segments far more than is comfortable. Our natural instincts are to go for a big, broad market. But that’s not a smart place to start. For example, if you were making a new tax prep product, you wouldn’t design it for, and market it to, every tax payer. Not at first. Then what people try to do is narrow things by demographics, but actually it’s usually more useful to narrow by use cases. This is what allows you to narrow scope of what you need to build. Still, it feels very uncomfortable. It feels risky. Don’t we want to go after a big market? Wouldn’t this put all of our eggs in one basket?

Let’s do an example first, before we handle those objections. It’s a useful exercise to try to narrow an initial customer segment so far that it becomes ridiculous, and only then pull back. So let’s take our new tax prep product: all taxpayers in the world is too big and messy. OK, how about USA taxpayers? Still too big with competition all over the place. USA taxpayers who have multiple forms of income (i.e. complexity but a specific kind). Let’s go further: USA taxpayers who have multiple forms of income and tend to be late in filing and paying due to that complexity. Further? Investors who have multiple pass-through vehicles (funds, spv’s, LLCs) that struggle to file/pay on time. Does it make sense to go further into VC vs PE vs individual investor? Arguably that is thinking too demographic rather than psychographic unless one of those segments has specific needs. Geographic region? Not sure why texas vs new york is that different unless we want to get into state taxes specifically. How about investors who have multiple pass-through vehicles which are no longer actively managed, and so information is not being shared out in a timely manner, thus triggering the late filing. Now too narrow? Maybe. This exercise is getting to the point where it’s exposing that I don’t know enough about the market, which is useful unto itself, no?

But you can see how narrowing the customer segment exposes certain pain points and can increase focus regarding the utility of the product. You then have to decide how much your narrow segment should drive the product design vs is useful primarily for go-to-market targeting. For product design, there are two aspects: 1) designing features specifically for a narrow use case; 2) using the narrow targeting to reduce scope, minimize all the edge cases you have to cover, etc. I think the answers to both #1 and #2 are very context specific.

Picking a narrow initial target doesn’t close off going after a big market — not on its own. Land and expand! I think there is an interesting balancing act between maximizing value to your early adopter while keeping an eye on that bigger market.

Yes, you want a big market, but you cannot go after everyone all at once. Not at the start. I’m a big believer in the technology adoption curve. If you start with “everyone” as a customer, that is the same as “no one”. You can’t skip over the early adopter to your mainstream adopter — the very definition of the mainstream adopter is they are waiting for the early adopter proof points.

But what if we choose the wrong market and it’s really narrow? Isn’t that putting our eggs in a single basket?

That is where research and experiments come in. Both are needed. I always say to people, if you have a strong hypothesis about A, go test that. If you really don’t know if it’s A or B, then make the tests smaller and faster and test both. Then pick the winner and keep on testing. I’m also not saying you have to pick only one, but more focus is usually better.

In other words, starting with a narrow market only limits the size of your overall market if you let it.

Full disclosure, I haven’t thought quite this rigorously in the past. Yes, I’ve always thought about the adoption curve and the importance of the early adopter. I’ve always thought in segments rather than personas. That said, I’ve kept things more vague than the above. It was listening to my fellow prod mgt professor at Stern, Andy Breen, on this topic that challenged my arguably lax thinking. I think this extra rigor is smart.

Of course this led to a question from a student: “If I’m targeting families traveling together with 4 or more people, should I not allow groups smaller than 4 to use my initial product?”

Fair question. Like all things in product, it depends. You have more questions to answer.

• Would it reduce scope / help us ship faster if we added that restriction?
• Would it help compensate for or overcome initial weakness in the product (examples: too little activity or users, too little info or inventory, a supply/demand imbalance)?
• Would it increase our brand cachet (the velvet rope syndrome)?

If you can’t think of a positive reason to add the constraint, I don’t think I would. I would design and market narrow, but allow organic usage and see if any interesting opportunities arise.

I also found myself giving feedback to students trying to narrow things down with either irrelevant information that had nothing to do with their use cases or with inner-mind psychological things that would be very hard to detect or target. You want your segment characteristics to feel actionable — either that you can find them or they can find you.

I think all of the above applies to teams working on features, not just new products. Every feature has an adoption curve of its own — sometimes they are just far more accelerated than you get with new products. In other words, companies have curves within the curve. As you expand with new segments and new features, you constantly take on new mini-adoption curves within your bigger adoption curve.

Last, more meta, point: I think it is very useful to try to push your thinking in many areas “to the bottom.” How much scope can you reduce before it’s no longer viable? How small can you take that experiment before the data is no longer useful? How narrow can you take your initial customer segment(s) before it’s ridiculous or foolish?

It’s by going too far that we discover the edges and can better evaluate the right decision.

Top image by Ibrahim Rifath on Unsplash

Ken Norton has an in-depth article pitching a dual-track product management career path. He doesn’t really speak to the economics, but that’s what I want to address because I think this is all about economics, or should I say, outdated economics.

When I ran Neo, which was an innovation consulting company, we had this challenge of wanting to hire or retain some highly talented individuals in PM, design, or engineering; at the time, salaries from the big tech companies were really starting to spike. Trying to compete didn’t make economic sense. We made money through human labor (charging for our time), so an employee delivered economic value to the firm by: A) selling a lot of business, or B) successfully managing more people. Yes, we also needed successful, well-run projects to continue to keep our brand strong, but that was long-term, indirect value. There was a ceiling to how far that could go, simply given our economics.

I hated that model, and that’s why I didn’t go to Pivotal when they acquired Neo. I was done with running a consulting business. Technology product businesses, on the other hand, have a different economic system. The value you can deliver to the business is not linearly tied to the number of humans thrown at a problem. A small number of people can deliver untold amounts of value. In this context, it makes sense to pay really talented people — those who want to work on asymmetric value creation — a lot of money because they will spot, execute, de-risk, and deliver that big value.

I think a lot of companies are still caught up with the more linear value-generation economics of the past. Manufacturing used to be labor-driven as well. They haven’t woken up to new possibilities. They haven’t re-thought what “good” could look like.

Having a dual-track option for exceptional PMs, designers, and engineers is not just a retention thing, it’s a good business decision. However, for it to be a good business decision, you need to be exploring and exploiting big new areas, or working to crack really hard problems that are holding you back. You wouldn’t want to pay exceptional rates for exceptional people and have them work on normal problems that anyone could work on.

In other words, a dual-track approach should be considered an important part of an effective innovation and growth strategy.

Smaller Thoughts of the Week

• PLG & org structure: I never found time to properly respond to OpenView’s article on product-led growth, but suffice it to say, I firmly, firmly believe this capability should report into product, not marketing, and not the CEO. And if you don’t have a growth and business oriented product leader, that’s the thing to fix. Having PLG teams report anywhere else is a poor workaround that will likely lead to a weaker and more disjointed customer experience and product/business strategy. One of the reasons you have an overall product leader is to have someone thinking holistically about the entire system.
• Title drops: I just watched a very talented female PM go from a smaller tech company to a much bigger one. In the process, she took a big hit to her title. Now, all the large tech companies like to shove everyone down a few notches, but I was shocked at how junior her new title was. I knew she was better than that title. I couldn’t help wonder how much of this had to do with her confidence and negotiation stance. And I think this happens more often with women than men, as a generalization. This is why I find it disgusting that many leaders still approach hiring as a “get away with what you can” mindset when it comes to salary and title. It’s simply a bad way to run a company, because eventually talent realizes what you’ve done, resents it, and leaves. Instead, create a clear skills and salary ladder and stick to it. Don’t let someone negotiate their way out of their proper band, and don’t try to under-pay, under-title someone just because you can. Makes me mad. Almost as mad as non-compete and non-solicit clauses (Earn the right to keep your people, don’t rely on legal intimidation!). Oh, and software patents. Yeah, okay, I guess a lot makes me mad.

Top image by DaYsO on Unsplash

The document Randy shared had 11 leadership tips for TV showrunners, and that list serves equally well as advice for founders. But that particular sentence brought me back to when I lived in Silicon Valley in the 1990s. Here’s what I saw: you could look to the person to your right (Sarah) and the person to your left (Sarafina). Both were equally smart, creative, ambitious, and hard-working. Yet Sarah was rich and Sarafina was still living paycheck to paycheck. The difference was that Sarah took a job at a winner and Sarafina didn’t. And by “didn’t”, I don’t mean that Sarafina necessarily picked a company that failed, but merely one that didn’t exit at the extreme-enough end of the spectrum to make those stock options “change your life” worthy.

But the way the world looked at Sarah versus Sarafina was very different. Sarah would be viewed as a bit of an oracle, as if she was personally responsible for the success of her company, rather than the excellent contributor she was. Sarafina was equally excellent, but didn’t have that glow. And if Sarafina’s company actually failed, as most startups do, she might even have a bit of a tarnish, through no real fault of her own.

This bias is bullshit, but you see it around you everywhere you look. I fall for it myself — it’s hard to resist.

When someone has a public win, they are suddenly transformed in the public eye. Chances are, to get that win, they are quite good — better than most, for sure —but they are still the same person the day after the win as the day before the win. Yet we put people on these absurd pedestals. It’s a dumb mental shortcut.

We seek speakers and thought leaders from the big, successful companies as if it’s a quality check, as if some of that success will rub off on us. Often this positive or negative judgement has nothing to do with the actual person, yet we fall prey to it anyway. I bet in August 2020, a conference organizer was excited to have a “Director of Product/Design/whatever” from WeWork as a speaker. I also bet that by October 2020 that same Director was persona non grata. Remember, we’re not talking about Adam Neumann here.

There’s a similar global dynamic where anything from “Silicon Valley” is put on a pedestal.

And of course, people try to hire from the successful brands as a de-risking shortcut, which in my experience actually isn’t that great of a de-risking strategy. Actually, sometimes it’s the opposite as that person flounders without the momentum or resources of an already-successful company. Sometimes, it’s even worse, and you realize that this big, successful company is actually quite backwards inside but they can get away with it because of their business moats. That’s not to say people from these companies are bad — my point is that using the brand name (whether a company or a school) isn’t a great mental shortcut.

This ties into the most common startup hiring mistake: hiring people way too far removed from their weight class. I know you want someone who can succeed when you are bigger, but you also need someone who can actually get you bigger from where you are today.

My former Meetup colleague Phil Calcado had a funny tweet the other day:

Things small & medium tech companies SHOULD copy from Google’s culture:
– Allow dogs in your office

Things small & medium tech companies SHOULD NOT copy from Google’s culture:
– Basically everything else

— Phil Calcado

Context matters. A PM (or marketer or any role) from Google is pretty much guaranteed to be very smart, but they come from a context with an unstoppable cash cow behind everything, huge amounts of traffic and data, and incredible resources. The way you need to do product management, or marketing, in that context is going to be different than most other companies.

When you read or hear advice, don’t accept or adopt it because such-and-such company does it. Ask yourself, “does this feel right for our context?” Yet, was I guilty of being extra-interested in “guilds and tribes” because Spotify was talking about it? You betcha. And then it came out that they weren’t even following some of the stuff they were writing about!

All that said, it IS really useful to collect different frameworks and tactics and advice because your context will change and all of a sudden your brain will go, “Aha! NOW I have a use for X!”

Resist the dumb mental shortcuts. Don’t be judgmental about people based on shallow evidence. Always remember context. Look for interesting and useful ideas, with less bias about the source.

If you’re coming out of a tarnished company, don’t despair. The world might judge you unfairly for a little bit, but hang in there. Your time will come.

And take a scan through the showrunner doc I mentioned at the start. It’s always fun to peek into another industry, rather than just be nose-down in tech.

Top image from Yan Ming on Unsplash

Hold those horses! If you just jump into a conversation, you risk several things happening: 1) the fast-ideas, heavy-talkers often dominate the conversation; 2) the first ideas are often not the best ideas; 3) you get an unhealthy dynamic called “group think”. I first learned about group think at university when we examined the terrible decision making under US President JFK that led to the Bay of Pigs fiasco. Group think is when the desire for consensus and group harmony overcomes critical thinking about ideas, leading to irrational decisions. There’s also a worse flavor where an intellectual bully makes it hard to dissent.

You can overcome group think by using what the design field calls diverge and converge. As those two words imply, first you allow people to think through an issue on their own, and then compare ideas in an attempt to find the optimal answer.

I use the diverge and converge technique for just about any situation where you want multiple perspectives into a decision. Need to align on resource allocation as an executive team? Diverge and converge. Need to design an experiment to prove out an idea? Diverge and converge. Need to prioritize the best opportunities to chase after? Diverge and converge. Want to think through the possible UX flow of an idea? Diverge and converge. Need to make an important technical choice? Diverge and converge.

You can diverge and converge in a meeting simply by giving people a few quiet minutes to think/write/sketch. But not everyone does their best work on the spot, in the moment.(1) Heaven forbid that our meetings have agendas and even, just maybe, a little bit of pre-work! However, what this requires is for you to put down your fire drills for a moment and do the prep work to make it easy for your attendees to do their prep work:

1. write down clear goals and constraints for the meeting
2. concisely explain, in broad-brush terms, the exercise you’ll be going through as a team
3. link out to any useful background information (such as qual/quant data summaries) on the topic
4. give people a little bit of homework, which might be as simple as “mull over this topic so you are ready for this exercise”

Remember, all of the above has to be concise or people will not read. Yes, this takes more work, but our whole field needs to set a higher bar for a meeting should be and how we use our meeting time together.

As a meeting designer (since that’s what you’re doing here), don’t assume that everyone will actually do their homework. People are busy. What is most important for you might not be most important for them. But some people will, and that will usually improve the quality of ideas that emerge and then converge.

Lastly, diverge and converge isn’t just for teams. It’s also for you, as a solo thinker. Humans have a tendency to get excited about their first ideas, but those first ideas aren’t always the best ones. Experienced designers learn not to accept their first concepts. Instead, they force themselves to sketch out multiple solutions to a problem, even some that feel dumb, just to stretch their thinking. This can feel painful, but it’s worth it. Jumping at one’s first idea is lazy, reactive thinking. The key to embracing this technique is choosing the desire for the best decision over a desire to feel clever.

And if you want a really interesting watch/read on more clearly thinking through product possibilities before jumping to a conclusion, check out Teresa Torres on critical thinking for product teams.

(1) I want to repeat what I said above: not everyone does their best work on the spot, in the moment, and/or in public. Ideally you don’t actually force your people to work that way. So take a look at how your company interviews — are you forcing people to dazzle on the spot, or are you coming up with other ways to let them reveal you their thoughtfulness? If you’re just doing the “dazzle me now” approach (looking at you Google, but they are far from alone), then you risk enforcing a bit of a mono-culture in terms of the kinds of people you hire. Maybe instead, try a design challenge or some new approach?

Top image from Javier Allegue Barros on Unsplash

As CPO, you spent 6 months looking for a senior PM to lead up a new effort. You went looking for a particular skillset in wearables, which is in high demand and short supply, and so were excited to land this person. The PM reports to a Director you trust, but 5 months after the PM starts, your Director comes to you and says, “I have surprising and unfortunate news. Our wearables PM says they are resigning. They have another offer, a higher offer with a higher title, from another company.” From your perspective one step removed, you’ve had a positive impression of this new PM, so this is bad news. What do you do next?

Before you read on (and even as you step through the case), go ahead and write down your actions/questions. If you want to jot down your own answers as you go along, open up this Google Form alongside. (Prompt 1)

.
.

If you’re like the Case Camp participants, you have lots of questions:

• why does the Director (the PM’s manager) think this happened and what has been their interactions with the PM over the past 5 months?
• what’s truly going on with the PM? Is it just a mercenary thing over title/salary or is it something else? (hint: it’s usually something else)
• what are the goals of this PM and have we truly been aligned?
• did we set the right comp/title for this person or did we miss something?
• how was this person onboarded to the company and to the team, and do we have a systemic problem there?
• how exactly are you going to gather this information?

You also have two planes to think about:

1. tactical: immediate needs of this situation (can/should this PM be “saved”?)
2. systemic: what weaknesses in our approach does this situation expose, and how to fix?

If you’re like most, you’ll probably begin by asking more questions in that first conversation with the Director when they break the news. Let’s say you discover a few things:

• the Director has been generally happy with the PM; yes, the team has been a bit rocky, but that’s why we wanted a senior PM on it in the first place; the team has been getting better — they always had clear goals but now their alignment, execution and communication seems to be improving;
• the Director has been checking in on the PM every couple of weeks, asking if they needed anything and the PM has been saying that everything is fine;
• for our company, we’ve got this PM at a correct title and salary level, if you don’t grant an exception for having rare knowledge about wearables;
• the PM’s goals, as understood, seemed what you would expect: work with good people on an interesting problem (specifically around wearables) and have a chance to get promoted — all of which we were offering;

A few things you also know about the Director: they are relatively new to the role, having been promoted 9 months ago, and have been stretched pretty thin lately.

Okay, now what are you going to do? (Prompt 2)

.
.

You might have picked up that the Director wasn’t too close to the PM — autonomy is fine and good, but they described flybys, not regular 1:1s. That’s not ideal. Given that the Director is new to the role, the responsibility for this really lies with you! From a systemic point of view: are you setting the right expectations and providing effective training and mentoring to your managers? On the tactical side: have you put too much on this Director’s plate, stretching them too thin when they need a chance to grow into the manager role?

It’s likely that you want to talk directly to the PM, both to learn more and potentially to sell them on staying. The question is how to do that?

• A. If you immediately go to the PM, that risks sending a signal that you lack of faith in the Director (both to the Director and to others). Even if you pride yourself on running low-hierarchy team, you have to be careful here.
• B. You could do a joint meeting, which has the benefit of getting to show the Director how you handle a situation like this. The downside is that it’s intimidating to the PM having to face 2 bosses, not just one, and is unlikely to get them to open up.
• C. I recommend asking permission of the Director to talk to the PM. When you talk to the PM, you can begin with something like, “I asked the Director if I could talk to you directly. I think you’ve been doing great work so far, so was disappointed to hear the news. Fill me in on what’s going on…”

(Prompt 3)

In this case, the PM still doesn’t open up. They respond, “Thank you so much for the opportunity to work here. I’ve learned a lot getting to work for you. I wasn’t actively interviewing, but got to know this other company last year. This seemed like an opportunity I’d be crazy to refuse.”
    “Well, I understand being excited about an opportunity,” you reply. “Tell me more about why you think you’d be crazy to refuse it.”
    “It’s a chance to lead a wearables team on an exciting new consumer product. It’s a great brand and great team.”
    “Well, I’ll admit that their brand is a bit shinier than ours,” you reply, “but I’d like to think you have an opportunity to do all of that here. You can make a great impact here, you know, and you’ve made a great start already. We’d love you to stay. I’d be happy to hear what you think that might need to look like.”
    They just nod, somewhat unhappily. “Thank you. Seriously, thank you, but I think I need to go.”
    “Where are you in the process with this other company?”
    “I’ve signed an offer letter.”
    “Ah, I see,” you say. “Well, you haven’t left yet and I’d hate to see you go. If the offer letter is like most in our field, then you can still change your mind, but I’m not here to pressure you to do so. I’d like to work out a path for you to stay, and would love for you to think about that as well. Let’s both think about what that could look like and talk again tomorrow.”

Keeping the PM feels unlikely given they have signed an offer letter, but it’s not unheard of. You have to decide if you match or beat the salary and title offer from the other company. What would you do? What are the pros and cons you see? (Prompt 4)

Within our cohorts, we were split on this topic. Some people thought that it would be acceptable to give the PM a raise because the negative impact of losing the PM to the team and an important project justify the outlay. Others thought it could be justified because the PM has a specialist skillset in high demand. Others felt like it would set a bad precedent and could cause downstream problems and resentment with the rest of the PM team. If the PM was truly being mercenary, you might be in the same spot in another 5 months.

For my part, I would be unlikely to match a competing offer. Different PMs all have different strengths and weaknesses, and I don’t believe in paying more to someone who negotiates more aggressively. I believe in having fair salary and skill bands that apply equally to the entire team. If the market has moved, I need to change my bands, not make one-off exceptions. I’m okay losing a candidate because I’ve seen the unfairness, bias, and subsequent morale problems that come with a “get away with what you can” approach to pay.

What you can do, however, is paint a clear picture of what the PM needs to do to get that promotion to the higher title/salary, and perhaps set expectations (not promises) around a likely time frame. But remember, as CPO you have to decide whether you do this or have your Director do this.

If you’re like me, you’re still thinking, “Even if the PM didn’t say anything, there’s got to be something else going on here.” The trouble with getting to the CxO level is your information flow from below becomes non-existent. People don’t tell you what is really going on. Nor can you invisibly observe the team meetings — people’s behavior changes when you are around, like it or not.

One possible solution: do you have another PM who might know what is going on and who will open up to you (since PMs often vent their frustrations to each other)? Or, is there someone else on the departing PM’s team whom you can talk to? For the latter, I might start with the designer, as they would be a close partner to the PM. If you are beyond startup size, you will want to give a heads up / ask permission of the design manager.

Note: these little permission steps are more than niceties. They preserve the mutual respect that is needed with your direct reports and which you can break with careless “skip levelling”.

In this case, the designer says this to you: “Yeah the rumor is already swirling that the PM might be leaving. I’m bummed. I liked working with them. The team was just getting its feet under it! I don’t really understand it.” When you press for friction or conflict anywhere, the designer admits, “Well, the PM was arguing a lot with J, our engineering team lead. I mean, we’re all used to J – they mean well, but they are really passionate and have strong opinions and can sometimes come on very strong.”

The engineer in question reports up to your peer, the CTO. At this point, you know my question: what’s your next move? (Prompt 5)

Most likely, you start with your peer, the CTO. You ask if they know anything about the relationship between the PM and the lead engineer, and they say, “Unfortunately I don’t. The lead reports to one of my VPs and I haven’t heard anything. I should note that this is one of my best engineering leaders. Yes, they can be stubborn and opinionated, but they’re not a jerk — I don’t allow jerks. I think you and I both know that they’re one of the people we can really count on to deliver something of technical quality.”

The CTO wants their VP to talk to the engineer before you or your Director does. The VP comes back to you and says, “Well, I spoke to J. They were surprised to be the cause of a resignation. They acknowledge some of the arguments — apparently they have been butting heads over speed versus quality — but said they would be willing to adjust their style and try to work better with the PM. They do like the PM, even if they think some of the PM’s instincts are going to get the project into trouble.”

At this point, while you might have some further investigations in mind, let’s say that you sit back down with the PM. What would you say? (Prompt 6)

.
.

Here’s what I might say:
    “I’ve been thinking about the situation here, and I’ve learned that you were having some difficulty with J on the team. Was that part of your reason for wanting to leave?”
    “I guess it contributed, yeah. I tried to resolve it, but didn’t make much headway,” the PM says.
    “It’s unfortunate that it got to this point. J does like working with you, and is willing to improve their style and develop a better working relationship. If that doesn’t work, we can consider remixing the team. I also think we, in product leadership, bear some responsibility for not onboarding you better into the team and perhaps for not laying out better ground rules for how strong differences of opinion should be handled and resolved. So we have some thinking and improving to do. I’d still like you to stay with the company. Have you thought about what that could or should look like on your end?”
    The PM shakes their head.
    “I have,” I say. “You’re on the right project — wearables is what you want to do, and it’s really important to the company. I also think you’re at the right salary and title for your level, but you should be going over that with your manager at least quarterly. We do rolling promotions here, so when you level up, you level up. We want to promote you, but we have a system that keeps everything fair in our organization and attempts to minimize bias, at least as best we can. We don’t make exceptions, and I hope you see that’s a better system to work within.”
    I continue, “I think there are areas for us to improve on our side. You should be having weekly or bi-weekly 1-on-1s with your manager. The Director agrees that should have been happening. If you felt on your own, that was not their intention. As I mentioned, I also think we can improve some things around team onboarding, building team empathy, and how team disagreements get escalated.”
    Then I get to the part about what the PM needs to do: “That said, I think there are some things for you to think about too. The most important is asking for help. This is as essential when you are an executive as when you are a brand new PM. Self-sufficiency is great, but only to a point. Asking for help is a sign of strength, not a sign of weakness. And we really could have helped here if we had known what was going on. In other words, it’s a two-way street. Your manager needs to paying more attention, but you also have a responsibility to bring your big challenges to their attention.”
    I conclude: “I know it might feel like a foregone conclusion, but it’s still very possible for you to change your mind and stay. I think there are opportunities for you to do great things. I think this has shown some opportunities for our company to grow, and for you also to grow. I’m hoping we can do that together. Think on it, and let me know later today or tomorrow.”

The next morning, the PM tells you they appreciated your comments, but that they are indeed going to leave. You accept your lumps, thank them for their time with the company, and focus your efforts on improving things so you don’t walk into this again.

Some takeaways

Here are a few questions to ask yourself about your own situation:

• Hiring: are we being clear about our culture and values, and what people should expect when they come to our company?
• Onboarding:
  • how are we onboarding people not just into the company but also into their teams?
  • do we have a diversity issue in terms of onboarding and assimilation into teams?
• Management:
  • have we provided the right training and expectations for the frequency and rough structure of 1:1s?
  • are we setting conditions where employees feel comfortable for help?
  • Are our managers putting responsibility on the employees to come to 1:1 with an agenda, and to raise challenges? (put another way, do we treat employees like adults or children? People will often act as you treat them)
  • Should we run periodic “stay interviews” to keep our finger on the pulse of why people are staying, yet also spot the issues that could tempt them to go?
• Teams
  • how are teams making decisions and handling disagreements? (note: I’m a big believer in escalation paths for the latter, rather than role-based decision “owners”)
  • How are we measuring the informal temperature and effectiveness of our cross-functional teams? Can we experiment with something lightweight?
  • can we suggest a menu of ongoing empathy/relationship building exercises to help teams come together (for example, user manual to me)

Final thoughts

I hope this case was interesting. Writing it up is certainly harder than talking about it live! The PM job really changes once you become an executive, and while, yes, you get to work on product strategy, your success really happens through other people.

As you can see, even a relatively simply situation has a lot of nuances. Seemingly simple decisions have downstream effects. We also have to be cautious with our own biases. Did, for example, you overlay specific genders on the case?

I should also note that while this case didn’t veer into the really tricky (and awful) territory of harrassment, sometimes that will happen. You need to make sure you bring in HR right away.

I can’t say that I would do it the same way every time, as context matters so much. You might have made different moves, and I’d love to hear what/why in the Google Form (Prompt 7) or over twitter (DM or open) or email. And if you are interested in Case Camp and want to learn more about the program, click here.

Top image from arash payam on Unsplash

p.s. thanks to my former colleague Brian Fernandez for the suggestion of adding the form prompts.