“Better” is better than perfect

The Overlap #15

Welcome to The Overlap, a biweekly newsletter that explores the relationship between product & organization design. It comes out every other Wednesday morning.

This one’s on how teams can shift their standards from perfect to better.

Productivity and perfect weeks

I fell in love with personal productivity in college. 

As I read more and more productivity blogs (with my newfound productivity powers), I started making little tweaks in my life: block scheduling my day, keeping my phone outside of my workspace (which was just my desk in my bedroom), and not working after dinner.

I grew obsessed with tweaking my daily habits. In 2015, I wrote about how I turned my college schedule into a workweek:

Let’s break it down:

1. Choose a work start time. (e.g., 10am)

2. Choose a work cutoff time. (e.g., 7:30pm)

3. Look at your weekly obligations and count the number of in-between hours between your start time and cutoff time.

Of course, reality never honored my vision of the “perfect” week. Reality presented unplanned things, like last-minute requests from my student org, interviews, and changes to my internship hours.

To go back to my 2015 essay:

Similar to the autopilot schedule, it won’t run perfectly at first. There will always be setbacks. You’ll wake up late, take longer than you planned on projects, and fight lost time because your meeting lasted 3 hours instead of 1.

What’s important is to gradually get better.

At first, adapting my ideal week to unplanned circumstances made me feel less productive. When I compared my planned week with my actual week, I felt like I accomplished nothing. I was frustrated. I was always at unease. I avoided opening my calendar because I didn’t like feeling “behind.” My actual week always looked different from my neatly planned week.

I learned that perfection was the wrong standard. And that I had to change it.

I eventually shifted my standards from hitting my week as planned to doing better than my previous week. Even if better was “My total hours that I spent writing this week was 30 minutes more than last week”, tiny improvements motivated me.

Perfectionism in teams

I feel like product teams also struggle with perfectionism.

Generally, product teams have:

• a plan they need to execute.

• several story points they need to have “Done” every week. 

• a metric/target they need to hit before a certain date.

Goals are fine. What’s less fine is if these goals are calibrated towards perfect rather than better.

If their progress doesn’t line up with the plan, if they’re not hitting as many story points as they’d like, if they aren’t going to hit the metric before 2020 is over, it’s worth questioning (and adjusting) the plan, target, or goal itself. Is this plan intended to build a perfect vision of the product? Or should we de-prioritize certain features so that we can focus on building the feature that’ll make our customer’s current reality better?

I like how Ryan Singer put it in Shape Up:

If we aim for an ideal perfect design, we’ll never get there. At the same time, we don’t want to lower our standards. How do we make the call to say what we have is good enough and move on?

It helps to shift the point of comparison. Instead of comparing up against the ideal, compare down to baseline—the current reality for customers. How do customers solve this problem today, without this feature? What’s the frustrating workaround that this feature eliminates? How much longer should customers put up with something that doesn’t work or wait for a solution because we aren’t sure if design A might be better than design B?

Seeing that our work so far is better than the current alternatives makes us feel better about the progress we’ve made. This motivates us to make calls on the things that are slowing us down. It’s less about us and more about value for the customer. It’s the difference between “never good enough” and “better than what they have now.” We can say “Okay, this isn’t perfect, but it definitely works and customers will feel like this is a big improvement for them.”

Make scope cuts by comparing down to baseline instead of up to some perfect ideal

For product teams, the standard should be better than what customers currently do to solve this problem rather than perfectly execute the business’s vision. 

Perfect as the standard makes the team, business, and customer unhappy. Better as the standard makes the team, business, and customer happier. 

Systemic perfectionism

Say you work with a product team at a large company. Your company believes that once they’re structured like Spotify, they’ve achieved the perfect org design. And the way your team gets funding for future projects is if they spend all the money that was handed to them by building what they’re instructed to build.

From Davide Tarascondi’s comment on Reimagine the Org Chart:

The problem I see of mapping out an organization starting from teams is that teams you are going to find are almost always a by-product of the traditional org chart even when they are represented with a hybrid, pseudo-Spotify, matrix-based model. What's worse is that layering a Spotify model on top of the traditional org chart is going to fracture the value stream even more.

Believing Spotify’s org design is perfect will backfire. Reorganizing into this “perfect” model (that many folks from Spotify say isn’t perfect) gets in the way of creating the value the org intends to create with that model.

What’s more is if you discover a less expensive way of building a feature, or a better way to build the feature based on new customer information, your team will still build what’s on the roadmap. From Melissa Perri’s Escaping the Build Trap:

‘They turn all these business cases into a giant roadmap for the year, give them out to each team, and fund the projects. At the end of the year, if they do not deliver what’s on the roadmap, they do not get as much funding next year.’ 

‘Do you realize what that means, Melissa?’ he asked me. ‘That means that, if a team finds a way to build a product cheaper — or finds that the product shouldn’t be built at all — they are building it anyway because they will be penalized if they don’t spend all their money.’

Yikes.

In large companies, it’s generally outside of the team’s control to shift the organization’s standards from perfect to better. You’ll hear responses to your proposed change:

• “This chart has to show growth or else our investors/board/shareholders will be upset. We can’t afford anything less than perfect.” 

• “This is the way we’ve always done things.”

• “If you aren’t executing to the plan, your team simply isn’t good enough.”

Changing the way organizations organize, budget, and allocate resources needs leadership buy-in, no matter how much the team is pushing for the changes.

So if you and your team don’t have that level of authority, what can you do to shift your org towards more realistic goals? When the org expects perfect, how can you get your team focused on better?

Focus on what you can control

The best thing you can do is to focus on what you can control.

Make it your team’s goal to improve a specific user outcome (rather than a specific customer segment or technology channel) and ask your leaders to support this goal.

Find an outcome that will cost a lot to the business if it isn’t improved. Maybe you’re working on a marketplace product. You find that a lot of users churn at first use because it takes them too long to find what they’re looking for. Reduce time to first search result by 20% can be this team’s metric. Clarify the team members, decision rights, and resources to get this work done, and ask leadership for support.

Your team can be the model for how other teams work. As you pilot this outcome-oriented way of working, be sure to continuously share with leaders and other teams what’s working and what isn’t, so that everyone is learning from it. Regular retrospectives help.

Perfection exists to put us on the path to better

I mentioned earlier that “did I hit my week as I planned?” became “did I do better than I did before?” My baseline became how I’ve done before instead of how well I want to do.

• “Did I spend less than $150 on eating out this month?” became “Did I spend less money on eating out this month?”

• “Was my discovery engagement less than 4 weeks?” became “Was my most recent discovery engagement shorter than my previous discovery engagement?”

• “Did I climb 5 times this week?” became “Did I send more projects this month than I did last month?”

Thing is, I don’t think I’d set “better” as a baseline if perfection didn’t kick my ass in the first place.

I appreciate Kevin Hart’s outlook on perfectionism:

Perfection doesn’t exist. You got one life. The goal for us is to live it to the best of our ability, from the beginning to the end. In the beginning and middle, you’re gonna fuck up. You’re supposed to learn. And move forward with the understanding of what not to do. And when you move forward, life may get better. It may not. But somewhere along the lines it’s gonna click. Everything I went through was supposed to happen. So now that I'm here I'm able to go ahead with such a high level of knowledge and I can make other people better. I can make myself better. I can do more for my family.

Although, I think I see perfection differently than Kevin. Perhaps perfection does exist. Perhaps it exists to teach us to adjust our expectations and put us on a path towards better.

---

What I’m Reading

1/ The difference between a journey map and a service blueprint

The journey map and service blueprint: two tools I’ve picked up at Sanctuary Computer. Both are great at aligning teams on 1) what customer pain points to solve and 2) how their teams can organize to solve that pain point. They’re great at helping teams think through their org design:

“Given this journey that we’ve detailed, what would this require from ops? From designers & devs? Is the way we’re currently structured set up for delivering this journey?”

I’ll do an edition of The Overlap that shares how I currently run these sessions with clients. I’d love to hear how you do them—leave me a reply or comment!

2/ It’s time to kill the org chart

Ironically, the first org chart was not a top-down hierarchy. It pushed authority to those closest to the information.

As historian Caitlin Rosenthal has written, the first organigram — an 1855 schema of the New York and Erie Railroad — was surprisingly modern. It looks organic, not man made, and it reversed assumptions of top-down power. The plan gives day-to-day authority to divisional heads, who “possessed the best operating data, were closer to the action, and . . . were best placed to manage the line’s persistent inefficiencies.

3/ Rethinking the Internet, Again

Speaking of decentralization, I just found out about Solid, a company trying to decentralize the web. Solid was started by the world wide web investor himself: Tim Bernes-Lee.

The core idea of Solid is that people house their digital data in decentralized servers called Pods. You can run your own Pod server, or use a third-party server hosted by a company you trust. The key is that no one organization controls everything. Instead, as with the classic web, all servers can be accessed using a common protocol.

When a web site or application wants to use some of your data, it must now ask you for permission. Using cryptographic tools, you can then grant the requester access to exactly the information you want it to have, and it can use your permission to go gather this data from the relevant Pods. The reverse can also happen: with the right permission, a service can write new things to one of your Pods, such as adding a new social link, or a note from a healthcare provider.

How psyched would you be if you owned your own data? If you could use Facebook, Instagram, or Tiktok without your data being productized? 

I’d be pretty psyched.

---

See you in two weeks,
–tim