Supervotes and Hierarchical Leadership vs. Aligned Goals and Self-Organization - Product Thoughts #121

If you're familiar with the concept of the Design Sprint, you probably have also come across of equipping the participating decider with something called a 'Supervote' for the decision making processes of a Design Sprint. The Supervote essentially trumps all other votes which have been placed, e.g. on scribbles or ideas.

Here's the official definition:

The supervote is the ultimate decision. Each Decider will get three special votes (with the Decider's initials on them!), and whatever they vote for is what your team will prototype and test. Deciders can choose ideas that were popular in the straw poll. Or they can choose to ignore the straw poll. They can spread out their votes, or put them all in one place. Basically, the Deciders can do whatever the heck they want.

Even though the typical Decider in a Design Sprint doesn't have to carry hierarchical power, it's often the case. So, the supervise is effectively the extension of hierarchical authority. 

It didn't bother me when I first read and learned about the design sprint many years ago, but just these days I noticed how rarely I used that concept in the past Design Sprints I've run.

It almost seems counterintuitive to introduce such a measure in a process which assembles a diverse and cross-functional team with flat hierarchies to identify a great product.

Of course, the 'typical' hierarchical leader would argue that you couldn't make sure that my team 'makes the right choice.' Moreover, that they would always need a failsafe to make sure the team does no damage.

If you're an avid follower of my thoughts, you know that I'm a big proponent of self-organized teams and leading without formal authority. A key ingredient for self-organized teams is alignment on what needs to be achieved. Also, amongst other, Objectives and Key Results (OKR) are a powerful way to align the goals of a team.

By framing OKR around outcomes, a given playground is set for the team to provide reaching their goals a fair shot. Ideally, the alignment and commitment of intentions lead to the hierarchical leader becoming redundant for the day-to-day business.

I mean, if you have aligned goals between leadership and the team, what could be reasons that you'd have to course correct their choice? Isn't it instead of a sign, that the wrong people are working on solving this problem if the choices were that bad/wrong (however you'd want to define this)?

Coming back to the concept of the Supervote, I'm starting to wonder why you'd want to keep this concept alive during a Design Sprint (or any ideation phase). Isn't it only a sign of saying: 'Vote what you want, but in the end, it's always my call'?

On the other hand, I can imagine a lot of leaders shying away from this specific moment of demonstrating their power. Taking-off your tie and calling everyone by their first name for the whole week, only to suddenly fall back into the paradigms of hierarchy? Instead, they probably generously hand full decision-making power to 'their' teams. Only to look at the results afterward wondering whether it's now too late to intervene...

I'm curious: What are your experiences with incorporating the Supervote into (otherwise pretty democratic) decision-making processes? Do you see Deciders overruling the team's tendency often?

Have a great week and take care,

Tim

What I read this week

Why PMs Should Carry a Sales Quota

Before you can assign your product team a quantifiable quota, there are a few things to consider to ensure you’re correctly enabling your product to be ready to sell. The first is to decide on either a freemium or free trial experience. The second is to transition to PQLs. The third is to know—and improve—your product’s time-to-value. Finally, you’ll want to optimize your product with personalized in-app experiences. Let’s explore how to do each of these four things.

Growth Hacking for Product Managers by Chris Long

Chris says that product managers often are unaware of their responsibility in the growth process. Although many areas in a business affect growth (product, marketing, engineering, data, design), the product manager is first and foremost responsible for the success of their product. A successful product, says Chris, is one that creates value for its users. Growth is getting more people experience this value.

The Story of Spotify Personas

Sometimes in order to move fast, you have to move slow. Foundational research initiatives, like the development of personas, take time and are resource intensive. Yet the learnings benefit us long into the future.

Q&A: Instagram’s New Head of Product, Vishal Shah

It’s also true that running Instagram today is fundamentally different than running Instagram, let alone six years ago, or even four years ago. There’s a business. It’s a billion people. Every decision that we make now has much broader impact. There’s regulatory considerations. There’s political considerations.

Avoiding The Wrong MVP Approach

Without writing any code, the team learned what they needed: customers could supply valuable pictures. That was only the first step, but it was a big one. (Next up: could they easily get those pictures into the existing claim system?) MVPs often don’t need code, but teams forget this. Our organizations are so used to solving every problem with software that we forget that we can learn what we need by faster, more effective means. The teams that use MVPs most effectively focus on what you need to learn first. Then they ask how they can best learn it. Often, you can avoid writing any code altogether.

Note: For more thoughts on this topic, check out this Twitter thread, which ended in a much more concise and jargon-free summary.

Agile won’t get you to Done; here are 4 ways to fix that

How do you know you’re done? For artists, this is a hard problem. (DaVinci is supposed to have said no work of art is ever finished, only abandoned.) But artists aren’t the only ones who struggle here. This is a hard problem for technology teams too. Tech teams have invented countless ways to solve this — with specifications documents and requirements documents. With acceptance criteria and user acceptance tests. And with what Scrum — the most widely adopted agile framework — calls the definition of “done.”

Hypermetricemia: A dangerous product disease that you can avoid

We’ve learned to measure success by numbers. Want to know whether a feature is successful? A/B test it. Was an ad successful? There are campaign metrics for that. Is a company successful? The numbers in the P&L statement and balance sheet should provide the answer. It seems that success can be defined by numbers. But strong metrics and big numbers often give the false impression of success — you may have a galloping horse but is it galloping in the direction you want? Is your “successful” company, product, or feature making the world a little more like the one you want to live in?

How to design internal products that are actually useful

Like any other product, an internal product is for the user: it needs to work for them to be able to achieve an outcome. There’s a myth that spending a lot of time researching and designing internal products isn’t as important as customer facing products. This means that there’s never enough time given to it, and things are simply shipped as fast as possible in order to increase team productivity. This may result as an immediate value and initial increase of productivity, and if something goes wrong, that would only impact internal users, no big deal.

Product Thoughts is a weekly newsletter/digest I send out to over a thousand leaders in product, UX, and business every week. To learn more about previous editions and sign up for it, go to herbig.co/newsletter.