Janna Bastow is co-founder of ProdPad, product management and roadmapping software for product people. Janna also organizes ProductTank and Mind the Product, a global community of product managers. She often starts — and stops — conversations with the question: “What problem are you trying to solve?”
[00:00:02] Hi. Thanks very much.
[00:00:06] "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 kind of wanted to work for Netflix. Now it's not their quote, this is actually from The Little Prince. But it's actually 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.
[00:01:07] 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 and to find out just what they have in common. Hi. By the way, I'm Janna Bastow I'm founder of ProdPad which is a roadmap and backlog software that's going to help you manage your product as it grows. I'm also co-founder of Mind the Product which is a community for product managers and a series of events around the world.
[00:01:51] 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 is a story of like this really treacherous time we had at ProdPad, 2015, 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 to some tactics that worked for us, but take what I say with a grain of salt.
[00:02:47] 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 excelling have strong established product cultures. A product culture is about how people interact with you and with the product. Do people in 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.
[00:03:43] 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 it 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.
[00:04:25] 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 on their team. Not everybody is at that stage. Not of us not all of us are that fancy. Not all of us have walls. It's easy to spot when a company doesn't have the product vision inline. I worked for a company quite a few years ago when we were at a job fair and a bunch of us, maybe 15 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 will give 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.
[00:05:20] 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 Jeffrey 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 is 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.
[00:06:14] All right. So you've got your vision, your team's onboard with your mission and your purpose and they're rearing 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 guardrails. That way they can be autonomous and still work on their own, but there are 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.
[00:06:51] Now I hear a lot of questions about you know KPI's versus OKR's 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, KPI's 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 onto 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. To resist the urge to do this.
[00:08:13] Now a product managers 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. 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 the 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.
[00:09:02] Now of course we all know Steve Blancs 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 you know 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 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.
[00:10:10] And this is a step that so often forgotten your customers come up with an idea, 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 are going to be going like "you know, are you actually listening to my feedback?". And if they get nothing back from you they're not going to keep giving you feedback. They're going to 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 to get more and more feedback from more and more customers, and what's a consistent feedback loop good for? Moving fast. Qasar talked about this just a couple of hours earlier, about how momentum is so important, and I can agree with him more. It's the single best thing you can do. You know screw working smarter, just move faster.
[00:11:27] 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 going to end up swinging wildly all over the place. You're going to be solving customer problems more quickly and getting to actual usage data so much faster. Last I heard Etsy was deploying 50 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, 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 missed 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.
[00:13:10] 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 that 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 learning 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 can 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.
[00:15:39] 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 road map might change as they go. So why is it that when I look up a 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, you know, by end of the year you're going to have all this stuff finished. Great. But it's setting you up for failure. Let's break this down.
[00:16:39] That sort of road map 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 seemed pretty easy and intuitive to use, you're mapping out your upcoming weeks and so you know you've got some good estimates, and your team's on board with this. They're OK with these delivery timelines. But the farther 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 roadmap. They always include some sort of due date and time estimate, whether you've explicitly written it on the roadmap, or whether it's just implicitly suggested by where they sit on the roadmap. 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 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 yea-big now it doesn't mean that your estimate of it being yea-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 we can be able to deliver or how long it's going to take. You're also implying 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?
[00:18:22] You're also making the assumption that each of these features will work as soon as they launch. You allowed yourself three weeks to build that new checkout page. Excellent. At the end of the three weeks it's launched, its 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 are 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 was right all along. So, what could possibly go wrong? Well it 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 roadmap.
[00:19:55] 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 roadmap 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 most 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 MVP's 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, is 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 roadmaps. We've got Foursquare, Slack, Intercom, and dozens of others out there who are actually publishing versions of their Now-Next-Future roadmaps 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.
[00:21:28] 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 [I'll] be back here in a few hours because Rosemary King is going to be diving 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 the 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 going to 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 helped set the stage for psychological safety.
[00:23:37] And there's a dynamic that's often overlooked when your 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. Well 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 me 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 5, 10 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.