Menu

Posts tagged “product management”

Remote product management: challenges and opportunities

Even though more and more companies are getting comfortable with remote work, the field of product management still seems to push back against this trend quite forcefully. There is a general sense that product managers can’t do the things they need to do unless they are physically located with their teams. This has some ironic consequences, such as that Slack — a company that builds a tool “where work happens” — doesn’t hire remote employees.

I confess that at first I was skeptical as well. But as we started to work together and make progress at Postmark, my skepticism fell away. I do believe it’s harder to make the product management role work remotely than some other roles like customer success or development. But it is possible, and I believe that companies need to start being more open to hiring remote product managers.

We often hear about the drawbacks of remote work, but it’s important to remember that there are certain things that remote work is naturally better suited for than on-premise work. Most importantly, remote work makes it much easier to develop and instill a rhythm of collaboration and focused time for a team. This rhythm will be different for every team, but I like to think of it as a wave. Here’s one example of what a cycle of private and public work could look like in a team:

Wave

Because it’s easier to shut down distractions as a remote worker, the deep work part of that cycle can be immensely efficient and dramatically increase both the speed and quality of work that gets done.

But of course, we can’t ignore the parts of remote work that are challenging and need to be figured out. So in this post I want to share a few lessons I’ve learned over the past 2 years that have helped me to overcome some of the more severe challenges to being an effective remote product manager.

In-person time is still important (but maybe not for the reason we think)

I joined Wildbit at the right time: one week before our yearly in-person company retreat. That gave me an opportunity to meet everyone in person, work together, and most importantly, have meals together. Once you’ve eaten a meal with someone, they’re not an anonymous “colleague” any more. Which means that when conflict arises (and of course it will), you’re way more likely to work through it kindly and respectfully. It’s very difficult to be mad at someone you’ve broken bread with.

The point is that in-person time is extremely important for remote teams. But you don’t need it every day, and the reason you need it is not to get more work done. The reason you need it is to sustain the human relationships that will enable you to get more work done.

When I spend time with our team in person, yes we spend quite a bit of time working together in meetings. But the biggest value for me is the lunches, the coffee chats, and the after-work catch-ups. That’s where we begin to see each other as whole people, and it’s at the core of our ability to work together and grow together.

This is certainly true for the whole team, but it’s especially true as a product manager, where your ability to do your job lives and dies with your ability to have good relationships with the team.

Love your tools (and be prepared to do a bit more of the heavy lifting)

One of our principles at Wildbit is that we optimize for asynchronous communication. We don’t hate meetings. We just value focused work extremely highly, so whenever we can we try to protect that work by giving each person the opportunity to work on something when it’s best for their schedule.

To make this work, you need tools. And those tools have to be light-weight and not a pain to use. Sure, we use Slack (although we’re trying to wean ourselves off it), but most of our collaboration work happens in Dropbox Paper and Basecamp. Those tools are designed for the type of collaboration and asynchronous communication that feels good. It can’t be overstated how important it is for remote teams to love their collaboration tools. If everyone hates the tools, the work will find a way to not get done. You’ll end up blaming “remote culture” and hire an onsite product manager, when the problem lies with crappy tools instead.

The catch is that these tools are just like comments on the internet: if you want them to be useful, you need to be prepared to spend quite a bit of time managing the process and the flow of information. As product manager a big part of my role has become making sure the right people know about things, and the wrong people don’t get distracted by things they don’t need to be involved in. This needs time and care, and doesn’t just happen automatically. The good news is this will still take way less time than “back-to-back meetings” every day…

Make prioritization and planning a team effort (and embrace the benefits of that)

Prioritization and planning of work is difficult under the most ideal circumstances. When you’re working on a remote team, the challenges are even bigger. This is where a combination of the right tools and some deliberate time management can make all the difference. The thing is, we know we do better work when all of our team’s perspectives are taken into consideration — not just in terms of the details of a project, but also what we should work on.

As product manager my role in the prioritization and project planning process is way more traffic controller than it is decider. We use our asynchronous tools to discuss ideas, post and gather feedback on initial drafts of plans, and occasionally even make radical changes to a plan as we learn more from customers and everyone on the team. My one goal is to keep the conversation going. It can be a little chaotic at the start, but I always feel like we end up in a better place than if we used a more traditional prioritization process.


Being a remote product manager is not without its challenges. It can be difficult to get the whole team aligned around a common vision, and you’re not always going to be able to get your questions answered right at the moment you want it. But if you can find a way to focus on and nurture the benefits that are unique to remote work, the challenges tend do get pushed to the background.

To put it another way, I understand why people think that product management isn’t a role that can be done remotely. There’s a lot of team communication involved, and of course that can be challenging over electronic channels. But with a slight shift in the lens you view product management through, those challenges fade away as the benefits of deliberate focused work and carefully considered collaboration come to fruition. I’ll say this: it’s totally worth it.

What is Twitter even for

Two lofty but surprisingly insightful Twitter think-pieces caught my attention this week. The first is Jennifer Senior’s description of it as The High School We Can’t Log Off From:

A few years back, the sociologist Robert Faris described high school to me as “a large box of strangers.” The kids don’t necessarily share much in common, after all; they just happen to be the same age and live in the same place. So what do they do in this giant box to give it order, structure? They divide into tribes and resort to aggression to determine status.

The same can be said of Twitter. It’s the ultimate large box of strangers. As in high school, Twitter denizens divide into tribes and bully to gain status; as in high school, too-confessional musings and dumb mistakes turn up in the wrong hands and end in humiliation.

The second is Ezra Klein’s pretty profound Twitter is not your friend. Here’s the crux of it:

We write for an audience we think we know, in a vernacular they’ll understand, using reference points they’re familiar with. Six years later, our tweets are weaponized to an audience we don’t know, thick with terms they understand differently, with the reference points completely absent. […]

Twitter is not your friend. It is built to reward us for snarky in-group communication and designed to encourage unintended out-group readership. It fosters both tribalism and tribal collision. It seduces you into thinking you’re writing for one community but it gives everyone the ability to search your words and project them forward in time and space and outward into another community at the point when it’ll do you maximum damage. It leaves you explaining jokes that can’t be explained to employers that don’t like jokes anyway.

And it’s not just what we write. It’s what we see. Our feeds are filled with reasonable, funny, thoughtful comments from our groups and the most unreasonable, offensive tweets sent by our out-groups.


My own experience has been similar recently. For years I used Twitter as a way to share things about product management and design, and in return, learn and get feedback from that community. Also the occasional joke. It was fun, and it played a really big role in my career development.

It’s not fun any more. Don’t get me wrong, I’m not mad about it. There are more important problems to solve right now than how I should approach a specific feature I’m struggling with. I’m not mad about how political Twitter has become. It kind of needs to be that, because that’s what’s important right now.

But I do feel like I’m not sure where to go to share ideas with my product tribe any more. And I’m also too scared to tweet anything personal, for all the reasons Jennifer and Era point out in the essays above.

2018 is so weird.

Where are your "invisible asymptotes"?

Eugene Wei’s Invisible asymptotes is a long, excellent article about the importance of not just thinking about product-market fit, but also product-market unfit:

For so many startups and even larger tech incumbents, the point at which they hit the shoulder in the S-curve is a mystery, and I suspect the failure to see it occurs much earlier. The good thing is that identifying the enemy sooner allows you to address it. We focus so much on product-market fit, but once companies have achieved some semblance of it, most should spend much more time on the problem of product-market unfit.

For me, in strategic planning, the question in building my forecast was to flush out what I call the invisible asymptote: a ceiling that our growth curve would bump its head against if we continued down our current path. It’s an important concept to understand for many people in a company, whether a CEO, a product person, or, as I was back then, a planner in finance.

He goes on to discuss those asymptotes for different companies (for example, shipping fees for Amazon). Another interesting bit:

We speak often of the economics concept of the demand curve, but in product there is another form of demand curve, and that is the contour of the customers’ demands of your product or service. How comforting it would be if it were flat, but as Bezos noted in his annual letter to shareholders, the arc of customer demands is long, but it bends ever upwards. It’s the job of each company, especially its product team, to continue to be in tune with the topology of this “demand curve.”

I see many companies spend time analyzing funnels and seeing who emerges out the bottom. As a company grows, though, and from the start, it’s just as important to look at those who never make it through the funnel, or who jump out of it at the very top. The product market fit gradient likely differs for each of your current and potential customer segments, and understanding how and why is a never-ending job.

Figuring out what your product’s invisible asymptotes are sounds like a really good thought process to me. At the beginning of the article Eugene mentions one way Amazon tried (and succeeded) in answering this question:

For people who did shop with us, we had, for some time, a pop-up survey that would appear right after you’d placed your order, at the end of the shopping cart process. It was a single question, asking why you didn’t purchase more often from Amazon.

Another technique he mentions:

One approach I’ve taken when talking to companies who are trying to achieve initial or new product-market fit is to ask them why every person in the world doesn’t use their product or service. If you ask yourself that, you’ll come up with all sorts of clear answers, and if you keep walking that road you’ll find the borders of your TAM taking on greater and greater definition.

A good way to frame this could be to ask yourself something like this:

If we didn’t change anything about [product name], at what point would we hit a growth ceiling, and what are the factors that would cause that?

If you can have a reasonably confident answer to where the S-curve inflection point will be, you can start planning on avoiding it early. That’s a worthy effort, and definitely something I intend to think through for our products.

Product managers: don’t play favorites with methods and techniques

While reading this great interview with the band CHVRCHES I came across a passage that struck me as a good description of how product managers should work. They describe the producer on their latest album like this:

And I think that’s why he’s so good at what he does. He’s not a kind of producer that has one thing that he does and he tries to make every artist do that thing. He steps into the room and tries to figure out the people that are in it and figure out the music they’re making, and then how can he add something to that and offer wisdom and guidance and make it better.

We all have methods and techniques we gravitate towards: Jobs-to-be-Done, Agile, customer journeys, sticky notes… It’s totally fine to have favorite methods that we know inside out and that have worked well in the past. But it would be a mistake to force one of our favorites on a team when it’s not the right thing for them.

One of the most difficult things a product manager needs to do is first understand how a team works and what makes them effective, and then figure out which methods and processes can create the right environment for them to thrive. That’s the skill that sets apart the great product managers from the good ones.

Tips for better estimates

Ah, estimates. That thing we all know we need to do (and get better at), but no one really wants to talk about. Well, Gina Trapani takes the topic head on in a great post called Estimation Is a Core Competency:

Estimates don’t need to be perfectly accurate as much as they need to be useful.

Good estimates create trust among your PMs and business leaders and collaborators. Being able to identify the risks and uncertainties in a project early gives your project team the information they need to plan around those risks and uncertainties.

Are you consistently getting waylaid by unforeseen work mid-flight, or just taking longer to execute on the work you did know about? That creates distrust between engineers and business leaders, and if it happens repeatedly, that distrust compounds and calcifies into resentment— that is, if you’re still in business.

Gina goes on to give some great tips for better (i.e. more useful) estimates.

“One Laptop Per Child”: a great solution to the wrong problem

Do you remember the “One Laptop Per Child” project? The PR event made a huge splash back in 2005, and I remember being really impressed and inspired. As it turns out, OLPC is a textbook example of what happens when an organization has a sincere desire to solve a problem that they simply don’t understand.

Adi Robertson, writing for The Verge, has an excellent history of the project called OLPC’s $100 laptop was going to change the world — then it all went wrong. It starts with this anecdote:

Then, Negroponte and Annan rose for a photo-op with two OLPC laptops, and reporters urged them to demonstrate the machines’ distinctive cranks. Annan’s crank handle fell off almost immediately. As he quietly reattached it, Negroponte managed half a turn before hitting the flat surface of the table. He awkwardly raised the laptop a few inches, trying to make space for a full rotation. “Maybe afterwards…” he trailed off, before sitting back down to field questions from the crowd. […]

If you remember the OLPC at all, you probably remember the hand crank. It was OLPC’s most striking technological innovation — and it was pure vaporware. Designers dropped the feature almost immediately after Negroponte’s announcement, because the winding process put stress on the laptop’s body and demanded energy that kids in very poor areas couldn’t spare. Every OLPC computer shipped with a standard power adapter.

As you read deeper, it becomes clear that they were working on a solution that didn’t take local issues into account at all:

Bender thinks OLPC might have struck more deals if it had focused less on technical efficiency. “Every conversation we ever had with any head of state — every time — they said, ‘Can we build the laptop in our country?’” he says. “We knew that by making the laptop in Shanghai, we could build the laptop [to be] much less expensive. And what we didn’t realize was that the price wasn’t what they were asking us about. They were asking us about pride, not price. They were asking us about control and ownership of the project.”

To put it another way:

OLPC had created a computer that could withstand dust and drops, but it hadn’t accounted for political messiness.

There are many lessons to learn from this story, but most important is almost certainly that a desire to do something good isn’t enough to make a product successful. If you don’t fully understand the problem you’re solving and the people you’re solving it for, your chances of success are incredibly low.

Tracking development uncertainty with hill charts

I read something recently that struck me as a really good idea for our team. Usually that feeling goes away after a couple of hours (“nah, it’s cool but not a good fit for us”) — but not this time. In Running in Circles, Ryan Singer talks about the knowns/unknowns in a project like a hill:

The most important question for a team isn’t “what is left?” but “what is unknown?” Can you see the edges? Have you gone in there and seen everything that needs to change? The only way to gain certainty is to roll up your sleeves and engage with the reality of problem.

At Basecamp our teams seek out the areas with the scariest unknowns and work on them first. This uphill work requires strategies. We wrote about these in Getting Real. Open the code, spike something that works, load it with real data and try it. When the whole feature is too big to prototype, factor out the most important pieces and spike them.

He has a a nice visualization of it:

He also uses an example from a recent project to show how they map this out:

As they “move over the hill”, different parts of the project become known, and they become more certain about what’s left to do. We’re working on some checklists to identify development risks before we start a project, and this looks like a great way to visualize those risks and track them as you go.

The humble product manager

When the design community wants to argue about something they fall back on the age-old question, “Should designers learn to code?” In the same way, for as long as the role has existed, the product management community has debated whether or not PMs should be referred to as “the CEO of the product.”

Neither debate will ever be settled — this is just something we do. But Marty Cagan does have a solid addition to this never-ending argument in his post CEO of the Product Revisited. His main point is this:

Now, the strong product manager does not need to be an expert in all of these many aspects of the business, any more than the CEO needs to be.

The key is that, like the CEO, the product manager needs to have a solid understanding of the many aspects of the business, and assimilate all of this information to make informed decisions.

But it is his focus on humility that I want to spend a moment of reflection on:

So going forward I’m going to continue to emphasize the importance of humility and earning the team’s trust, but I will also start emphasizing and embracing the positive aspects of the similarities of the PM role to the CEO.

A call for humility in product management is not something I see very often. This is strange to me, because I find this to be an extraordinarily humbling profession. There is so much to learn and do that I am not sure how anyone can think of themselves as an “expert” in the product role.

At one extreme, PMs need to be confident about the decisions they make. They need to keep learning and growing, and hone their craft constantly. Solid theory and excellent technique need to become so ingrained that they simply become second nature, cornerstones of everything they do.

But equally important — and this is why humility is so important — they need to be open to the possibility that some of their decisions might be wrong. They should hang on to a measure of self-doubt every time they present a new solution to the team or the world. Admitting that someone else’s ideas are better than your own, and making changes based on good critique do wonders to improve products — and build trust within the team.

In the design context John Lilly phrases this in a way that should become a mantra for all product managers: “Design like you’re right; listen like you’re wrong.”

Product management for maturing products

Janna Bastow wrote a great post on product management for maturing products. From Growing up Lean: Lean Strategies for Maturing Products, here’s a recommendation for how to avoid becoming a “Feature Factory”:

Break the backlog up into two parts: The Product Backlog and the Development Backlog. […]

Product Backlog: A list of all of the things you could do. You’ll never complete everything on this list, and it’ll always be in a constant state of flux. It’ll include customer requests, suggestions from your team, through to insights from your experiments and prototypes. It should be accessible by your team, to both contribute and follow along on progress – your team should be helping to build and flesh out the ideas in your backlog. This is your space to prototype and spec out ideas, map them to your objectives, and track their progress until ready for production.

This is similar to how we do things at Postmark. Here is our Releases board in JIRA:

JIRA releases board

You’ll see that we have our short-term planning (the Development Backlog), that currently only covers 2018.2 and 2018.3 (roughly 6 weeks each). And then we have the mysterious Later release… that’s the Product Backlog. It’s that list of all the things we could do. When we do short-term planning we pull from that list, as well as other areas (most notably, our “Idea Zone” in Basecamp, which I should also write about at some point).


I’ve written about maturing products before as well. I’m happy to see that Jenna and I bring up similar points. Here’s a quote from my post Product Management for well-established products, which echoes some of her thoughts:

With an established product, it’s way too easy to get off track (Evernote, anyone…?). So what I argue for is a flexible quarterly roadmap of prioritized themes. You don’t write down dates next to a long list of features. You don’t make hard commitments for releases that might never happen.

Instead, you put together a list of themes you’d like to work on, in order of priority, based on how closely they align with your objectives and key results for the quarter.

How YouTube leads viewers down a rabbit hole of extremism

Two related articles about YouTube caught my eye over the past few days. The first, Zeynep Tufekci’s YouTube, the Great Radicalizer explains how YouTube’s algorithms almost always lead people to conspiracy theory videos:

It seems as if you are never “hard core” enough for YouTube’s recommendation algorithm. It promotes, recommends and disseminates videos in a manner that appears to constantly up the stakes. Given its billion or so users, YouTube may be one of the most powerful radicalizing instruments of the 21st century. […]

What we are witnessing is the computational exploitation of a natural human desire: to look “behind the curtain,” to dig deeper into something that engages us. As we click and click, we are carried along by the exciting sensation of uncovering more secrets and deeper truths. YouTube leads viewers down a rabbit hole of extremism, while Google racks up the ad sales.

This is bad enough, but then there’s James Cook’s article YouTube suggested conspiracy videos to children using its Kids app, in which he explains how not even the YouTube Kids app is immune to this:

YouTube’s app specifically for children is meant to filter out adult content and provide a “world of learning and fun,” but Business Insider found that YouTube Kids featured many conspiracy theory videos which make claims that the world is flat, that the moon landing was faked, and that the planet is ruled by reptile-human hybrids.

I try not to be too quick to call technology evil, but this is definitely not a “all technology is neutral” situation. Product managers and developers have the power to stop this kind of escalation from happening.