In order to build products people love in today’s fast-moving world we need to be experts on everything from design to engineering to machine learning. Since no one person can have all those skills it’s critical that we stop worrying about titles and build cross-functional teams who combine all this knowledge and experience with the autonomy to execute. In this talk Martin will show the benefits of thinking cross-functionally and how to set up teams for success this way.
← All talks 
Build Product Turing Fest 2018
You Are All Product Managers
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Good morning, everyone. So software is eating the world. You've all heard this before because Marc Andreessen said it way back in two thousand eleven. That's seven years ago. That's forty nine years in dog years, but I'm pretty sure it's over a hundred years in Internet years.
But take a moment to think about just how much has happened in that time. Back then, Uber was a simple black car service just in San Francisco. Today, it's worth a faintly credible sixty two billion dollars. It's the world's largest taxi company and yet it owns no cars.
Airbnb had just gotten started. Today, it's worth forty two billion dollars. It's the world's largest hotel and yet owns no real estate. And in that time, Alibaba has grown to a juggernaut worth nearly four hundred and ninety five billion dollars. It's the world's largest retailer and yet it owns no inventory.
So clearly something is happening. Something has changed. And it's not just the new entrants either. Because back then ExxonMobil, Chevron, and Walmart were all in the top five of the S and P five hundred. But today, it's completely dominated by tech companies. And the transformation isn't done.
Mark himself has updated his own quote to software is programming the world. Because the transformation is speeding up with disruptive new companies, technologies, and products springing up every single day. Some of them just capture our imagination for a short while, but others point to exciting new futures, which may or may not disrupt how we do everything.
So not only is software eating the world, it's also moving faster and faster and faster. In fact, the rate of change today is the slowest that any of us will ever experience. So as Hilde and Brian said, my name is Martin Erickson, although I'm sometimes better known as the big friendly giant for obvious reasons.
And I started building stuff online when the Internet still came on floppies. In fact, I can claim to have beaten Snapchat, Periscope, and Facebook Live to the punch by over twenty years by hosting the first online livestream in Europe. Of course, it did take about five engineers and a giant satellite truck from the local telco just to make the thing run.
The video quality was so terrible, I don't even have a screenshot to show you. And seeing it was a student orchestra festival at my university, I'm not sure the sound was much better either. Since then, I've cofounded the world's largest community for product managers.
Together with Jana and James are here as well. We have over a hundred and fifty five meetups around the world and annual conferences in London, San Francisco, Hamburg, Manchester, and more. In the last two years, I've also been working with these two guys on a book about product leadership.
This was at one of our writing retreats at Muir Beach. But other than just hanging out at cool Airbnbs, we also spent two years interviewing hundreds of product leaders from all over the world, from startups to corporates to figure out what it is that makes us tick.
And just recently, I've also joined part time at EQT Ventures, is one of Europe's largest venture and private equity firms to help our portfolio companies excel in this area. And I do all of these things because I'm fascinated by how we keep up with this brutal pace of change.
And I'm fascinated to figure out how we can build better products. And in order to do that, first, we have to figure out what software eating the world really means. It means that in our interface to the world around us is changing. And I'm not just talking about our user interface.
It's worth digging into Marc Andreessen's original quote a little deeper where he said that all of the technology required to transform industries through software finally works and can be widely delivered at global scale. Now this is a really fundamental shift that I think we forget about because we're so close to it.
It means that how we interact with technology itself is changing. New interaction models keep popping up trying to tear us away from our clunky old desktops. First came mobile, then wearables. And then all at once, it seems like augmented reality, virtual reality, voice, bots, AI seem to be changing how we use technology and how we interact with it.
And as builders, this means that technology is moving faster and faster and requires more and more specialized skills. Of course, how we interact with each other is also changing. Every day, a new paradigm for social interaction pops up from the heady old days of email.
Trust me. It was really revolutionary when it came along. The chat tools, Snapchat, video apps. Who here could have predicted how quickly Slack was gonna take over our working lives? But perhaps most fundamentally, how we interact with business is changing. We're seeing the emergence of lots and lots of new business models.
Try to remember just how revolutionary software as a service was just ten years ago. I launched the first recruitment software as a service in Europe. We weren't even called SaaS back then. We were called application service providers. And in the past few years, we've also seen the dominance of the App Store model, experimentation and subscription models, pricing models, DLC and games, and so much more.
Today, you can even subscribe to a Volvo or a Porsche, at least if you live in London, and walk away whenever you want. So this new interface builds on a combination of insane advances in technology, new business models, and a design and user experience discipline that's making technology more human centric every single day.
And ultimately, that's why we are all here today. Because we are the ones building that new interface. But that's also why it's so damn hard because it any new innovation intersects business, technology, and user experience. No one discipline can solve all the challenges that all three face.
So whether we're product managers, founders, designers, data scientists, product owners, we are all product managers and that intersection is where we live. Together, in the middle of a Venn diagram, it's a slightly weird place to call home, but we're real geeks here. Right? So let's let's just roll with it.
So I implore you to ignore the semantics of your titles to and the endless debate of who owns the user, who owns the code, who owns the interface. I say who cares? Because we all own the products and we are all product managers.
But this shared ownership requires a new way of working and that's what I wanna talk to you guys about today. Like any good heist movie, it starts with assembling your team. As Hilde pointed out, I'm somewhat famous for having drawn this Venn diagram that defines product management as the intersection intersection of the customer, the technology, and the business.
The problem with this is everybody thinks that everyone on the team has to look like this. When, of course, we all look like this, like this, or like this. And it's only when we come together as a team that we have all the skills needed in order to build great products.
And in fact, there's probably a dozen more circles that overlap those. Which is why it's so important to think about what skills you need and really map out your team and your needs against it. So you're bringing in different contexts, different experiences, different insights to your team.
Now, this isn't a definitive list of skills that you need to think about, but it's a model that you can use to try and think about your teams. Because as you start mapping people out, you can see where you have gaps, where they overlap, where they complement each other, and where you need to bring in new ideas and new skills to complement that.
And the reason this is so important is that diverse teams are simply better at solving problems. Decades and decades of research by organizational scientists, psychologists, sociologists, economists, demographers show us that socially diverse groups are more innovative than homogenous groups. And that's so important when we're building product because it lets us find that empathy with our customers.
Because those people aren't only bringing new information to the team. Simply interacting with people of different backgrounds, with different experiences, different skill sets, different education force us to prepare better and have empathy within our teams. And that then helps us find that empathy with our customers.
And if that's not enough, let me appeal to your bottom line. McKinsey recently released a huge study of over a thousand companies across fifteen years that showed that the companies that are in the top quartile for diversity are a whopping thirty five percent more likely to outperform their industry in profitability and value creation.
At the end of the day, product is a team sport. But as we all know, as soon as you have more than one team in an organization and you need them to interact with each other, you introduce friction. And this friction between teams is why we have libraries full of project management books, project management methodologies, inboxes, outboxes, dependency management, all this all this stuff.
It's all friction. And as you know, friction kills momentum. Friction kills speed. So to me, it's important that we put all these skills, these amazing cross functional skills into one cross functional team. Because it's only by bringing together a knowledge of the problem space that our user research and our designers can bring with knowledge of the solution space that our engineers and designers can bring, that we find that opportunity for great products.
And when I say cross functional, I mean really cross functional. You have to ensure that everything the team needs is in the team. My favorite example of this is TransferWise. I think somebody from TransferWise is speaking later today. TransferWise is an online currency transfer platform.
It's a startup based in London. They're a billion plus valuation. The best example I have is their currencies team, which is responsible for launching new currency transfer paths. So for example, when they launched transferring pounds to dollars, this was a team that was responsible for doing that.
As you can imagine, it's a little bit more complicated than just adding that option in a drop down. They had to go to the US and open bank accounts so people could move money in and out. They had to change their terms and conditions and their contracts, make sure that they were complying with local securities and money laundering laws.
In any other organization, this would have meant that that team had to go hat in hand to the banking department, ask them to help open up a bank account, wait six months for that to be a priority for the banking team, then take their hat in hand, go to the legal department, ask for permission to change the contract, wait six months for that to be a priority in that team.
So TransferWise did this completely differently. They actually embedded a full time lawyer and a full time banker in that team. So not only do they have product design and engineering, they have bank the banker and the lawyer, and they have everything they need in that team.
And they never have to go to another team to ask for help. I recently met a data scientist, an amazing data scientist, from a Fortune fifty company in the US who proudly pronounced that they worked for the research and insight division. Think about that for a moment.
A division responsible for research and insights. On the one hand, it sounds kind of fantastic. Right? A whole division. All these amazing, smart people. Think about all the amazing groundbreaking research we can do. The customer surveys we can do. The ethnographic studies. The data collection.
So much research. And then think about the bureaucratic nightmare that's caused by being in a separate division. Imagine the request forms. Imagine the prioritization and gatekeeping needed to safeguard that process. Imagine having to write a business case to get the research to write a business case.
So now that we have our amazing cross functional team full of rock stars with diverse skills and experiences, it's also important to let them create their own destiny and empower them with autonomy. We don't work in cotton mills or factories anymore. So why are we using the management styles that came out of them?
Command and control made a ton of sense when managers had all the knowledge and all the skills and labor was a literal human resource that needed to be corralled, told what to do, and managed. But it doesn't work like that anymore. And we forget that most of the agile and lean methodologies that we use today came from the Toyota production system.
They came from the factory floor. And they're fantastic if you've designed a Toyota Prius and you want to build it as cheaply, efficiently, and error free as possible. But what we've forgotten along the way is that the team that designed the Toyota Prius doesn't work that way.
They just can't. At the end of the day, your team is smarter than you. They're more informed than you. They're closer to the problem than you. They're closer to the customer than you are. So why are you telling them what to do? Instead, we need to empower our teams and we need to embrace autonomy.
We need to let these teams use all of those amazing skills and experience and resources to get on with the job of solving the customer problem. Because autonomy is one of the key motivators for most of us. Dan Ping covered this in his book, Drive, the surprising truth about what motivates us, based on a ton of research out of MIT, where they looked at the old carrot and stick model of financial incentives and realized that after a certain point, it simply doesn't incentivize the right behavior.
It doesn't lead to better or more innovative products. Autonomy also scales better because you can spin up new nuclear teams whenever you need to to tackle more products, more customers, new markets. You don't need to figure out how to scale a team beyond its breaking point.
And by removing layers of decision making between the customer and the team that actually makes the decision, it makes you much much faster and you can respond to new customer problems, new market demand, new trends much faster. Now, a lot of people hear autonomy and they think it means anarchy.
They think it means anyone can do whatever they want. We can come and go as we please. We can work on whatever we want. We can tell the boss to go stuff it. But the key to successful autonomy is to do it with accountability.
It only works when teams don't just feel ownership of the process and of what they build, but they actually feel ownership of a customer outcome. Because then they're going to live or die by that outcome. And that means leadership still has a huge role to play by setting the vision, the mission, and the goals that the teams are tasked with executing.
Leadership's biggest job is to ensure the alignment between these teams and so that each one doesn't just know what their goals are, but how those goals tie back to the company goals and what everyone else is working on. Henrik Nieberg, who's the infamous possibly agile coach and organizational coach behind the Spotify model, drew this out in a great two by two chart.
I'll remap that alignment and autonomy. And if you start in the bottom left corner, this is your classic micromanaging organization with an indifferent culture. You move up the alignment scale but without autonomy. You get your conformist culture with an authoritative organization where the boss is telling you exactly what to do but also how to do it.
If you move up the autonomy scale without alignment, it's probably like most startups, at least the ones I worked at, where you have kind of a chaotic culture entrepreneurial organization, you kind of hope somebody is actually working on the problem. And like any consultant will tell you, you want to be in the top right corner of a two by two with high autonomy and high alignment.
You get an innovative organization with a collaborative culture. With the leadership, it's still important to set the goals, but it's up to the team to figure out how to get there. True autonomy means removing any dependencies and any reliance on shared resources. Any team should be able to change any part of the product if it furthers their goals.
So for example, marketing should never have to wait for product or engineering in order to launch the things that they need to drive new customers to the product. A true growth marketing team can't stop at the landing page. They have to follow their cohorts all the way through conversion and retention in order to know whether that channel or that marketing campaign was actually successful.
Autonomy also means that everybody gets involved and brings all of these amazing skills that we put on the team to bear on all the challenges. Because only by co creating can we bring all of that experience to bear. As Marty Kagan, who's probably the godfather of modern product management said, if you're only using your engineers to code, you're probably only getting half their value.
And I would argue that this is actually true for all of us. If you're only using your designers to push pixels, you're only getting half their value. If you're only using your product managers to groom backlogs, you're definitely only getting half their value.
So get your engineers involved in design discussions. Get your designers involved in engineering discussions. And get everybody involved in customer research. Because insight, inspiration, and great product ideas come from the least expected corners. I still remember what is probably my proudest moment as a product manager, is many years ago in London.
I was working at a SaaS company building collaboration software, and we were experimenting with this new way of working. We'd already set up semi autonomous teams with design, engineering, and a product manager. And And we were small startups and when they had two of them, we'd rotate them between business as usual and new big product features.
And one day when we were kicking off one of those big new features, we got everybody together to kick it off We were calling sprint zero at the time to figure out what was the problem we were actually trying to solve. What was the job that we actually needed to get done?
And when I mean everyone, I mean everyone. We got the team together, but we also had sales, marketing, operations, customer support in the room to give their feedback and share their insight. And once we briefed everyone on the goals, the problem that we were trying to solve, the data that we had gathered to validate how important that problem was to our customers, that's when the magic happened.
Because I didn't write a single story that went into that feature. I didn't sketch a single wireframe. I was barely involved after that point. I could move on to the next thing. The team came up with all the product features. They came up with all the ideas.
And perhaps most importantly, one of the junior developers, a new guy, brand new out of school, had barely been on the job a couple of months, came up with what became the cornerstone feature. The feature that solved eighty percent of the problem with like a day's work.
The feature that I could never have come up with because I didn't understand the solution space as well as he did. Now, it's not always perfect. Sometimes a team looked like this as well. But the point is it's better to have that friction, that conflict, that debate internally than to push it out to your customers.
And to facilitate all this cross functional goodness, I think it's really important that these teams are co located. I know this is really hard for some organizations and not everyone agrees with me, but I find it so incredibly valuable. The high bandwidth communication that this allows is critical to a successful team and thus a successful product.
Even perhaps the world's most famous product designer, Johnny Ive, knows this. Now many assume that Apple, Johnny Ive, Steve Jobs before him, design everything in their ivory tower studio with no input, no user research. But it's just not true. Apple's new headquarters are a stunning piece of design.
But the reason I get really excited about it is that like all good design, it's the physical embodiment of these principles. This new way of working. Because a huge reason for how they built this, how they designed it, is to encourage more interaction between different skill sets and to allow teams of varied skills to sit and work with each other.
As Johnny himself said late last year, it's one of the things that he's absurdly excited about the new campus. Because at the moment, there's a number of really disconnected physical studios. And now they can all share the same space. They can have industrial designers sat next to a font designer, sat next to a sound designer, sat next to a motion graphics expert, sat next to a color designer, sat next to a soft materials expert.
I've worked remotely and colocated in different countries and different cultures. And I can tell you that there's simply no replacement for the level of communication afforded by simply sitting next to someone else on your team and to be able to see, hear, and understand their context.
So as product managers, founders, and leaders, it's so important that we design the space that we work in as well. And it doesn't mean spending a fortune on high design and star architects like Apple. Although, let's face it, if you can afford to, why wouldn't you?
But it does mean being conscious of our working environment, our working practices, and our physical environment. Because sharing a physical space and being able to use physical artifacts can impact how you set up your process. Zing, which is the leading professional network in Germany, the LinkedIn of Germany, you will, has this amazing concept of Auldraigsklarung.
Don't worry. I'm not gonna ask anyone to spell it or repeat it afterwards. And this is a template, a paper template for how they pitch, how they discuss, and how they monitor their product ideas. Each team prepares this giant a zero poster as their pitch for resources.
They maintain it as they learn new things and challenge their assumptions. They present to each other regularly. And then, most importantly, they hang it up on their wall so that passersby can understand what everyone is working on at a glance. And the format of the canvas doesn't matter.
It could be the lean canvas. Could be a business model canvas. It can be something you design yourself. It could be a road map. What matters is the interaction that this physical artifact encourages and allows and how it makes alignment between autonomous teams almost effortless.
And you don't even have to travel that far to see this in practice. This is an example from gov. Uk. And let's face it, if the UK government can do it, none of us have an excuse. But as you walk through these spaces, these teams, and you see cross functional teams co creating together every day.
You see walls and tables covered in post it notes where teams are aligning on the solutions for their customers. You'll see video calls where they're talking to their customer regularly to validate them. And it's just an amazing way to work. So bringing it all together, how do you actually get this done?
Well, you're a leader, a founder, a product leader, start by assembling your team and making sure that they're diverse, cross functional, and colocated. Set them up for success by thinking about psychological safety, autonomy, and motivation. And then pick the right process that balances discovery and delivery so each side of the team gets equal say.
Because as managers, our job is to get out of the way. Now, not everybody is a leader. Not everyone feels like they can change the organization and that's okay. Because if you're part of a team, start small. Show, don't tell. Change how you work before you try to change the company.
Pull in other team members into your work because they will return the favor and you will start getting those conversations happening. And finally, whatever you do, make sure that your goals, even if they're just your personal goals that your boss is giving you, are aligned with your customer and start getting that thinking into the organization.
Because when you're part of a team, your job is to get in the way. Because teams focus on customers and leaders focus on culture. Because our culture and how we work is just as important, if not more important than what we ship at the end of the day.
It's what lets us ship the right products to the right customer forever. And remember that we all own the products. We are all product managers. So embrace this autonomy, not just to build amazing products, but to build amazing teams. And remember that if software is eating the world, we are the ones writing the menu.
Thank you.