How to assess what your product culture is like, tips for building a healthy product culture, and how it’s going to help you build better products.
← All talks 
Build Product Turing Fest 2017
The Power of Product Culture
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Hi, thanks very much. If you want to build a ship, don't drum up the people to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea. When I read this quote, I kinda wanted to work for Netflix.
Now it's not their quote, this is actually from the Little Prince. But it's actually in this, it's with this quote that they close out their culture guideline, that they host on their job site. And everything about this guideline just screams good product culture.
It's no mistake that Netflix has become this incredible company with this successful set of products. But you know what their document doesn't talk about at all? There's no mention of foosball tables, or games rooms, or beer fridges. Stuff like that might give you a short term edge on hiring and keeping some talented people, but it's not going to help you move mountains.
And actually, I take back what I said. I don't want to work for Netflix. I want to build a company like Netflix, or like Google, or Slack, or Spotify, or Amazon. These are all known to be fabulously successful product centric companies. And over the course of my career, I've had the chance to work with companies such as these to find out just what they have in common.
Hi, by the way, I'm Jana Bastow. I'm founder of Prodpad, which is a roadmap and backlog software that's gonna help you manage your product as it grows. I'm also cofounder of Mind the Product, which is a, a community for product managers and a series of events around the world.
But along the way, I've also done a whole bunch of consulting, mentoring, training, and just lots of work with product teams all around the world. This is just to say that I've spoken to a lot of product teams. And I'm really excited to be back here at Turing Fest.
Thank you so much for having me last year. I talked to you guys about the power of product focus. It was a story of like this really treacherous time we had at Prodpad, twenty fifteen. We had a year of faffing about. We lost our focus.
And so the story was about how we reignited our growth by focusing on one key metric at a time. Now, our secret to growth was to fix onboarding. But of course, that was just our strategy. I walked you guys through some tactics that worked for us.
But take what I say with a grain of salt. Actually, take everything you hear today with a grain of salt because honestly, a founder giving you advice on what made them successful is like them sharing the lottery numbers that they used to win the jackpot.
There might be a great story in how they picked those numbers, but really it's not going to apply and help you with your product. Instead, look deeper into the company. Look beyond the vision. Look at their culture. All these companies that are selling have strong, established product cultures.
A product culture is about how people interact with you and with the product. Do people on your team feel comfortable sharing suggestions with you? Do they think in terms of solving and helping out with problems? Are people pitching in and are they challenging themselves?
These things don't happen overnight. A good product culture evolves. And I like to think about product culture as like a product in itself, something that you can measure and iterate upon and improve. And I'd argue that the product culture is the most important product that you're ever going to work on.
So I've looked at and I've pulled together some of the common threads that we're seeing the most successful product companies do based on everything that they do beyond the tactics, beyond the strategies. What bubbles up as the most common threads? Well for starters, they all have a vision of their future that the team can get behind.
Now some companies might get fancy with it and put it in big letters on their wall. It's a great approach for more mature companies who have this set vision and are ready to blast that out there to everybody in their team. Not everybody's at that stage, not all us are that fancy, not all of us have walls.
It's easy to spot when a company doesn't have their product vision in line. I worked for a company, quite a few years ago when we were at a job fair. And a bunch of us, maybe fifteen of us, were, from the company representing, talking to potential hires.
And somebody had gone around and spoken to different people on the team. And when he got to me, he pointed out, you know, I've asked everybody on your team what you do. And you all gave me a different answer. What do you do?
And I realized right then and there, we had a major vision alignment problem. We just did not know what we're supposed to be doing in the long run. So if you don't have one, don't fret. Here's a nice little guide you can use.
Now this is actually, borrowed from Geoffrey Moore's book, Crossing the Chasm. It was originally an elevator pitch, template. But really, it works really well as a product vision template as well, because it's asking the, you know, who you're building for, and what you're looking to be, and what you're looking to achieve.
So work with your team, fill this out, work with maybe somebody on the wordsmithing side to finesse it and turn it into something that you want to share and shout out to your customers and to your team. But at the end of the day, this is something that's going to help make sure everybody's pointing in the right direction.
Once you're done with this, print it out, get it stuck on the walls around the office, share it with the team, make sure everybody has access to this, so that when they're asked what the vision is, they're all on the same page. All right, so you've got your vision, your team's on board with your mission and your purpose, and they're raring to go.
So they're all pointed in the right direction. How do you actually keep them pointed in that direction? Well, having consistent objectives is going to help keep them within their, their guardrails. That way they can be autonomous and still, work on their own, but they're all working towards the same goals.
Now these are some of the objectives that I use, I build a SaaS product. But your objectives might be different, depending on the product area that you're in. Now, I hear a lot of questions about, you know, KPIs versus OKRs versus whatever the cool kids are calling them today.
Now if you ever want to start a fight on the Internet, go and tell somebody, write a comment saying that these two things are basically the same. But that's what I'm going to say. Honestly, KPIs were just sort of used and abused, and they weren't done properly, so they came up with something new and called it objectives and key results.
But it's the same concept. It's all about measuring the outcome of your performance. The outcomes over just what's actually being done. You're not looking at the vanity metrics, the output. And there's one trap that I see product people falling in all the time, and it's this one where you finish that release.
Good job, it's out there, it's live. So you close all the tickets in Jira, or in Trello, or whatever you're using, and you crumple up all the post it notes on the wall. And you move on to the next thing, because you're done, you're good to go.
But what tends to happen is that you move straight on to the next thing, and forget about actually going back and measuring. You know, why did we start this thing? What was the actual objective that we had with this? So instead of crumpling up your old releases and your old notes, actually hold onto them and make sure that you're actually solving the problem that you came in there to do.
So resist the urge to do this. Now a product manager's role, and the role of the whole team, is to invent a solution on behalf of the customers. And yet whenever I talk to product managers, there's always this feeling that they don't spend enough time with their customers, really figuring out their needs.
And there's a whole word for this process, product discovery. Being close to your customers is at the absolute heart of product discovery. It's uncomfortable, but without customers, we tend to have blinders on, and we don't think of the wider set of potential ideas or solutions we could use to solve their problems.
We don't understand the full problems that they have. We don't really think about the impact of new features. Every customer interaction should be a chance to learn something, another chance to connect the dots. Now of course we all know Steve Blank's age old advice of get out of the building.
Now there's some impracticalities with always being out of the building, particularly if you're perhaps a remote worker, or if your office building isn't in some thriving hub where your customers happen to be standing around. So don't take this literally, this also means bringing your customers in.
Either bringing them in for a coffee to meet with the team, or finding a space for them. For us, we actually created a digital space. We created a Slack group. And this is a Slack group just for our customers. It started off with this really small circle, and it kind of grew from there.
Now our customers interact in there, they help each other out, but also our entire team, the engineers, our marketing team, everybody in the company has access to this and can jump in on conversations and directly interact with customers and learn from them. Now warning bells should be going off.
This is a tactic. This is what worked for us. This doesn't necessarily work for you, but think about ways that you can open the doors to your customers. And this is a step that's so often forgotten. Your customers come up with an idea.
They're like, I got this great idea. Wouldn't it be great if you did this? Now, they don't expect you to build something immediately, but if you never get back to them, they're going to be confused. They're going to be wondering. They're going be going like, you know, are you actually listening to my feedback?
And if they get nothing back from you, they're not gonna keep giving you feedback. They're gonna think that you don't actually build anything based on what customers talk about or ask about. So it's so important to close the loop. Make sure that you're reporting this feedback and the original context of what they asked for, making sure that you can link it back to, you know, when Joe asked for this feature, what did he actually say?
Was it about this, or was the problem, the original problem, more about this? And once you've actually done this, it actually helps you nail a consistent feedback loop. You're going get more and more feedback from more and more customers. And what's a consistent feedback loop good for?
Moving fast. Kassler talked about this, just a couple hours earlier, about how momentum is so important, and I can't agree with him more. It's the single best thing you can do. You know, screw working smarter, just move faster. Moving faster allows you to take more shots on the net.
More shots on the net is more iterations. The more you iterate, the more you learn. It keeps your team focused on that MVP, building the minimum thing that they can to solve a problem and learn from it. As long as you have that solid vision and the objectives that we talked about, you're not gonna end up swinging wildly all over the place.
You're gonna be solving customer problems more quickly and getting to actual usage data so much faster. Last I heard, Etsy was deploying fifty times a day. And Amazon, I mean, you know, they've got this fancy one hour shipping thing, which is awesome, But try beating a deployment cycle of eleven point six seconds.
That's incredible. Last year, here at Turing Fest, I talked about this plateau of doom. And there's one data point that maps almost perfectly to our growth rate, our MRR growth. It was the number of releases per month. We shut down new development. We were a tiny team, very few resources, but we knew we had to rebuild our product.
And so we ended up having to rebuild this product and stop building for the old version of it. And that's when we flatlined. Once we doubled down and focused on delivering experiments, getting stuff out there to the customers, just releasing a few times a week, the numbers shot right back up.
Coincidence? Not so sure. We'd sort of miss something that's obvious in hindsight, continuous delivery and the value of it. We skimped on it because the infrastructure is hard and we thought it was going to be unnecessary. But the thing is, continuous delivery means continuous iteration.
And what's continuous iteration if it's not the essence of agile? And without continuous iteration, you can't have continuous learning. And what is continuous learning other than being lean? So simply by not being able to deliver quickly, regardless of what it was we were delivering, we weren't able to learn, we weren't able to be lean.
Agility is simply the organization's ability to quickly respond to the market. So we were missing a trick, and as it turns out, just forcing ourselves to move faster made a bigger impact than almost anything we did. Now we all know this build, measure, learn diagram.
But a lot of people take this move fast thing a little bit too literally, and they end up with the build build build cycle. Because measuring and learn takes time, and you're not actually getting stuff out the door. Right? It's called the build trap, and it's a dangerous one.
If you're stuck in the build trap, it's possibly because you've got a traditional agile, development process where you've got a two week segment, and you've agreed on what you're going to build over those two weeks. You launch it, and then you're ready to move into the next two weeks, where you've got another stack of stories ready to go.
What's missing in there is this cycle, this ability to go back and actually find out whether what you built was useful, whether what you plan on doing for the next sprint is actually still useful. So there's this, newer version called the dual track agile.
And there's a lot of different ways of doing it, and again, you could probably start a fight on the internet by pointing out how you do it and how that's wrong or right. But you can avoid the build trap by implementing something like this.
And the concept of it is that you've got a discovery track and a delivery track. The discovery track is basically the space, the permission your company has given itself to go back and look at what's been working, what's not working, to rethink what's coming up in the pipeline, and make sure that you're still on track.
So it's not all just about build, build, build. It's not just about the delivery, you're also spending that time to learn and iterate properly. This gives you the best combo of speed and learning. Product companies are also known for being open to change, or at least the best product companies are.
They know that things that are coming up on the roadmap might change as they go. So why is it that when I look up product roadmap in Google images, this is what I see. It's basically Gantt chart after Gantt chart. A whole bunch of nicely colored, but effectively timelines of what these companies really ambitiously think they're going to achieve.
I implore you to ditch the timeline roadmap. Thank you. Now I know this format makes you look great today. Your execs love this. The board loves when you can give them this level of certainty and, you know, promise them that, that by end of the year, you're gonna have all this stuff finished.
Great. But it's setting you up for failure. Let's break this down. That sort of roadmap format is basically a chart that maps out time on the x axis, and things to do on the y axis. The x axis is basically your timeline. And at first, it seems pretty easy and intuitive to use.
You're mapping out your upcoming weeks, and you know, you've got some good estimates and your team's on board with this. They're okay with these delivery timelines. But the further out you plan, and the more you put on there, the harder it becomes to manage.
Because that timeline always sits at the top, always marching you forward, no matter what you put on the road map. They always include some sort of due dates and time estimate, whether you've explicitly written it on the road map, or whether it's just implicitly suggested by where they sit on the road map.
And as a result, you end up with a big pile of features, a big pile of deadlines, and a really big pile of assumptions. So let's look at these assumptions. The first one you've made with this assumption is that, you understand how long each of these is going to take.
Again, this might be easy when you're talking about things in the short term, but just because something is yay big now, it doesn't mean that your estimate of it being yay big when you're delivering it six months from now is going to be true.
You don't even know how big your team's going to be in six months' time, let alone how fast you're going be able to deliver or how long it's going to take. You're also applying that you know that nothing else is going to come in there to mess up your timeline.
No changes in the market. No new competitors. No fresh ideas coming from customers that you might want to consider. No need for iteration, right? You're also making the assumption that each of these features will work as soon as they launch. You know, you allowed yourselves three weeks to build that new checkout page.
Excellent. At the end of the three weeks, it's launched, it's live, good job, you hit the due date. Is it actually converting at the level that you wanted it to? And by explicitly adding these features to the timeline, you're making the assumption that these features actually deserve to exist.
That these were the right things to build in the first place. That they form part of your strategy and therefore should be codified as part of your roadmap. At the end of the day, you're making a pretty big and dangerous assumption that nothing was going to change, and that your original plan, it was right all along.
So, what could possibly go wrong? Well, could lead you towards a whole bunch of unhappy times. You know, you've got made up release dates stomping you towards death marches for your team. You've got your product and your sales and your marketing people with mismanaged expectations.
You might miss some opportunities, or hell, you might just build the wrong thing. And that leads to you guys being sad product managers. We don't want any of this. So is there a better way? Sure. There's this new thing called time horizons. And the concept of a time horizon is that you do away with the timeline, and instead you have three buckets, the current, the near term, and the future, sometimes known as the now, next future, or a lean road map.
The idea is that the stuff that's in the current term is probably agreed upon. You've got some releases coming up, so you can put that on your road map and say this is where we are. The things in the near term tend to be a little bit less granular, a little bit more broad, and more flexible.
If something changes in the current term, you can change on that. And the future is more or less made up of things that are almost like placeholders. Problems that you know you need to solve in order to meet your vision, but that if things change, if the market shifts, then you can remove them.
You can move them around on your roadmap. Because at the end of the day, your roadmap is meant to be a prototype for your strategy. Just as your paper prototypes or your MVPs are meant to be prototypes for some new feature that you test out and find out what works, Your roadmap is there to test out whether your grand plan actually resonates with the market.
It's something that your team believes in and actually wants to see happen. If it's something that your customers and your board can get behind. Having a massive fixed roadmap doesn't give you the chance to be agile in the long run. And we're not the only ones doing this.
More and more, we're seeing this pattern of these now, next, future, or lean road maps. We've got Foursquare, Slack, Intercom, and dozens of others out there who are actually publishing versions of their now, next, future road maps out there. So there's definitely a shift in what we're seeing, and hopefully we'll start seeing the Google Image search results update as well with this.
It's also super important to have a team that's empowered. The best product companies out there empower their team by being open to input. It's important to remember that it's not your job to have all the answers. You're supposed to know less than your colleagues.
Instead, focus on asking the best questions. Ask open questions and use prompts to get people to continue their train of thought. Go on. What else? Tell me what you really think. Get your team to talk to you. A good product culture builds psychological safety within their company.
It's about making people feel comfortable speaking up, reporting errors that they find, or pitching in to help out with the product. Now, be back here in a few hours because Rosemary King is going to be diving into, into psychological safety a little bit more.
But there's a couple tweaks to your language that you can bring into your company to build this psychological safety. Phrase questions. So they begin with, how might we? It turns the issue into a collective problem. It supposes instead of asserts. And it works really well in conjunction with, I bet.
As a product manager, you're gonna be wrong a lot. I bet gives you and gives your team permission to fail and try again. After all, it wasn't you that was wrong. It was your hypothesis. And now that you know what doesn't work, you're free to go and try the next thing.
It's really subtle, but this healthy language, these shifts in language really help set the stage for psychological safety. And there's a dynamic that's often overlooked when you're a product manager. You're in the middle, and you're often treated as the lifeline to your execs, even if you don't have any direct authority.
You want to make sure that your team has your back. You need to make sure that you've got theirs too, and can show it. For example, when a point is raised, make a concerted effort to echo back their opinions using the name of that person.
I like what Sam said when she recommended we so and so. Mark had a great point about that earlier. Elevate the voices of those around you to make your team feel valued. It helps cultivate that right culture. I'm excited. I'm excited by a trend that I'm seeing.
The rise of the CPO, the chief product officer. It's a role that a handful of you in here might have today, but that five, ten years ago barely existed. We didn't have a seat at the table. Product leaders are being born every day, and finally being given responsibility, recognition, a seat at the table, a real chance to influence and craft a product culture.
It's only by building a strong product culture that the best companies in the world can build the products that people love. Thank you. We've got a couple, two minutes. Are there any questions for Jana in the audience? If you've got a question burning, raise your hand.
Colin, can we get a here's a microphone. Hi, Jana. Thanks for the talk. Really, really interesting. Thank you. Got a question about when you had this, like, graph of the I don't know if you could break it back up. Yeah. Absolutely. You saw this, like, plateau moment, and you talked about how you you decided to go and I don't know if you could use the word re architect, but you're going to take stock and rebuild your platform.
I was curious, how do you know it was the right time to do that? Mean, the product's four years old at that point. So So, I mean, is a real technical diagram of what actually happened in that year. But there were a lot of different moving parts that happened.
One was, the the product was built by myself and my cofounder. Neither one of us are actual developers, so what we built and had out there in front of a couple hundred customers, was perhaps on the unstable side. So we knew that we had to rebuild the product using professional developers, which, hey, thanks to customers, we could finally afford.
But what we hadn't counted on was how much effort we put into building the tool itself, and how many different pieces of functionality, how much customers actually depended on it. So when it came to building this new version, we knew that it had to have more or less feature parity.
We couldn't just take away all the functionality we'd given. But we also hadn't documented it along the way. We hadn't really thought about how big this thing was. So was by pulling it apart, realized that what we thought was going be a six month rebuild turned into an eighteen month rebuild, part of which time we actually stopped developing on the old version because, well, we were transitioning to the new one.
Great. That's really interesting. So it's partly product and partly technical for the reasons? There was definitely some technical reasons behind it. We also saw some opportunities that, you know, if we wanted to make it, translatable and mobile friendly and, faster, you know, you can only get so much speed out of a jQuery and Bootstrap app.
We needed to move to something, you know, all the new kids were on Angular at the time, so that's what we built it in. We've since rebuilt again. That was fun. That's another story. Thank you very much. Of course. One more. Question about your timeline less product road maps, which I fully support.
Love it. The challenge I face, given I've got general enterprise customers, is they want to know when they're going to get it. How do you, ratify those two sort of almost opposing things? Yeah. I mean, there's a couple of different ways that companies make money.
One of which is by selling big chunks of work to big companies, and agreeing on this massive scope, and then using that money to go hire project managers and plan it all out, and make the promises on those dates. That's an agency. That's not a product company.
If you know what it is you're building, there's nothing wrong with making money in that style, and there's a lot of money to be made in that style. And some companies have a blended approach. But it is important to remember that there's a difference between, product management and project management aspect of things.
Sometimes it is necessary to take on projects to fund the product growth, but overall, unless that what that company is asking for perfectly aligns with what the mass market wants, which it never does. We've tried this. It's going to end up where you, you know, end up building something extra.
And if you wanna make those dates, you add the buffer, and you spend the extra time on it. And that's one of the problems with the timeline road map is that, you know, you can put dates on it and promise those dates, But you're probably having to over egg it by at least fifty percent, and that's time that your competitors, if they're not building big projects like that, if they're not building for one customer, they're busy learning and iterating, and building faster than you, and surpassing you with the mass market offering,
which is where real growth comes from. Thanks, Janet. Let's give everyone a round of applause. Thank you.