2022-10-28
Every startup begins as the ideal product org structure. Everyone is focused on the customer. Everyone is doing what they can to make the company successful. Everyone cares more about doing the most important thing for the company vs the most important thing for themselves [1]. The team is the company. This leads to a “we” mentality.
I don't know why, but at some point every company seems to get infected with a different way of thinking. Teams start to care about their own success more than the company's success [2]. Individuals start to care about their promotions more than their products. And the customer is the ultimate loser in all this. This leads to a “me” mentality.
Part of the reason I joined Mutiny was to see if we could build a different type of product organization. One where engineers care about product decisions as much as technical decisions. One where designers care about business impact as much as product impact. One where product managers care about customer problems more than their own [3]. Building great products is a team sport. Everyone brings expertise and focus. But stellar experiences can only come from everyone deeply caring about the whole thing.
Teams are a byproduct of their rituals and incentives. If you don’t have a forum for all product managers to cross-pollinate ideas, you won’t have a cohesive roadmap or product. If you keep marketing design and product design crits separate, don’t be surprised when your website looks nothing like your product. If you promote based on launching new things, expect to see lots of new things. If you promote based on strategy docs, get ready for more docs with the word "strategy" in them [4].
So how are we doing things differently at Mutiny?
We structure our teams in pods with a product manager, product designer, tech lead, and 3-8 engineers. Each pod has their own weekly planning cadence. But we hold a jam session every Friday with all the product managers and designers. This is not a formal product review, which we hold separately. This is a casual environment to share insights and discuss top of minds. Anyone can propose a topic. The most interesting is usually pretty obvious. Then we go deep on it. This is really important to keep every product manager and designer thinking about “the most important thing” regardless of their individual scope. It might not have direct impact on your area. It might not become relevant until months later. But constantly shaping the same ball of clay keeps us aligned [5].
It’s no secret that I strongly believe in full stack design. I saw the power of it at Square and haven’t looked back. Now that we have a head of design (who also came from Square), we are doubling down here. Everything your customer sees is part of the experience. Your brand, your website, your decks, your app, your support docs — it’s all connected. The way you express your brand promise and the way you fulfill it should speak the same language and tone. This can only happen when brand, marketing design, product design, and research are critiquing each others work. Our design team is small but growing, so its important to establish these rituals early.
I can’t tell you the number of organizations I’ve seen who talk about the importance of metrics, then go on to completely ignore them. The problem is that a savvy product manager or product analyst can always explain a problem away.
Oh, that’s just seasonality. It’ll bounce back.
There was a change in our tracking last week so it’s going to look weird for a little.
That’s a hard metric to move. Let’s check back in a month.
We have a weekly metrics review that is all action-oriented, and I love it. Product managers and tech leads are expected to come to the meeting with notes and actions for every key metric. If a failure rate increased, they come with the relevant PRs and fixes in motion. If a satisfaction score decreased, they already watched the Fullstory sessions and have interviews scheduled. It’s magical to see the detail and rigor that comes out of this.
Most teams have some form of testing and quality assurance process. But there are two very different mindsets you can bring. The more common approach is to make sure it is functional. When you press the button, does it do the thing? When you look at the page, does it have all the things? This leaves a lot to be desired. What does it look like for new users? Existing users? Power users? What happens when you jump into the flow from weird entry points? Are the loading patterns annoying on slow networks? Are the animations tight? Does the spacing breathe? How does it feel? These are not always in the PRD. And you can’t always catch them in design review. But people are too afraid to mention them because “it’s ready to ship” and the deadline is tomorrow.
I hate to break it to you, but launching a crappy experience on time is still launching a crappy experience. The quality of your product will regress to the average you allow it to over time. When you hold an incredibly high bar in these launch reviews — and hold back launches because of “polish” — it teaches everyone what to expect. They don’t even bother bringing a feature to it unless they think it has a shot at passing the bar. And when it does, it feels so good. But it takes discpline and a shared appreciation for quality across every member of the team. It means leadership has to be okay with a slipped deadline because the team decided it wasn’t good enough [6].
I won’t claim any of these practices in isolation to be unique. But the intensity and care we have for them in aggregate is special. And we are right at the beginning. I want to build a team where product managers, designers, and engineers welcome debate at every stage. The trap that teams fall into as they grow is the allure of specialization. They mistake titles with concern. I want product managers excited when engineers interrogate their decisions. I want designers seeking more time to jam with their product managers. I want everyone caring about the quality of our decisions, designs, and delivery. That is what our customers deserve.
If this sounds like the kind of team you want to be a part of (or know someone who would), we're hiring and would love to hear from you.
[1] Someone is going to misinterpret this as me not caring about personal growth. My stance is that the best personal growth comes from putting yourself into positions of high potential and optimizing for the outcome. Yes, you can still get burned and not get the proper recognition. But that is ultimately out of your control. And focusing too much on it yourself distracts from the outcome.
[2] The telltale sign this is happening is when team-specific swag becomes the currency of status. Don't get me wrong, I love company swag as much as the next person. But when every team feels the need to have their identity on a t-shirt more the company's mission, something is off.
[3] This is one of my biggest gripes with product management becoming a more prestigious role. There is a slew of people who want to be a product manager so they appear more important, not because they care about the problems they are solving. This is the easiest thing for me to screen out in the interview process.
[4] I intentionally did not say you will see more strategy docs. Why? Because most promo cycles don’t actually assess the content of these docs. They use words as proxies. So if your doc says the word “strategy” more (bonus points for including it in the title), then it will be viewed as such.
[5] I got rid of these for one week because I was afraid it was a waste of time. The team asked to bring them back, citing it as one of the most valuable hours of the week. A good example of efficiency vs efficacy.
[6] There are rare instances where the deadline is truly set in stone (e.g. compliance). The company needs to plan for those immovable rocks far enough in advance so teams have buffer and can shift resources to accommodate.