As product leaders, we’re rarely hired to build a product from scratch. Unless, of course, you’re the founder. Much of the time we’re handed our predecessor’s backlog with little guidance – other than, perhaps, “Here, help us with this.” And with that, you’re faced with a decision to make, as introduced by Janna Bastow: press forward, predictably and safely, in a project-led mindset. Or change tack, introducing the thrill of possibility and risk into a product-led process.

In this episode of the Product Momentum Podcast Sean and Paul are joined by Janna Bastow, co-founder of ProdPad, ProductTank, and Mind the Product. Janna discusses the tension within organizations between the predictability that shareholders long for, and the uncertain sprint-to-sprint existence of the product manager.

“The people who are investing in your company are watching your stocks,” Janna says. “They want predictability at that level. They don’t care about the individual product features and, you know, agile vs. waterfall vs. whatever else. To them, Agile is just a means to the end.”

But for product managers, predictability is often just as risky as innovation. To us, Agile helps us run our experiments we need – some of which lead to innovation. It’s not reasonable to expect us to know what the results of these experiment are, though. Janna suggests that product leaders should work with management to carve out the freedom and budget to find the right balance between predictability and possibility.

Podcast: Play in new window | Download

Sean [00:00:19] Hello and welcome to the Product Momentum Podcast. This is a podcast intended to entertain, educate, celebrate, and give a little back to the product leadership community.

Paul [00:00:32] Hey folks and welcome to the show. Today, Sean and I are going to talk to Janna Bastow. She’s been a fixture of product management since the very beginning of Mind the Product Conferences. We’re going to talk about the difference between product- and project-led teams. We’re going to talk about how product managers are becoming more and more business leaders within their organizations. And then we’re going to zoom way out and talk about risk and opportunities and how to create opportunities for leadership and generate predictability in teams. All this and a lot, lot more. Thanks for joining us. And let’s get after it.

Paul [00:01:04] Well, hello and welcome to the podcast. I’m Paul Gebel, and I’m joined, as always, by my co-host Sean Flaherty. We’re excited to be joined today by Janna Bastow. She’s the co-founder of ProductPad, a product management and road-mapping software for product people. Janna is also a co-founder of Product Tank and Mind the Product, the global community of product managers. She often starts and stops conversations with the question: “What problem are you trying to solve?” Janna, welcome to the show. So glad to have you.

Janna [00:01:29] Wonderful. Thanks so much for having me today.

Paul [00:01:31] Absolutely. So to kick things off, when we were chatting before the show, we were kind of talking about different kinds of teams and how to think organizationally about how product fits in teams. So just to kind of help bring our listeners up to speed into some terms that we might use in the conversation, you know, as we begin down a path with a team and inertia picks up, it becomes harder and harder to step away and see the big picture, like, “where are we situated and what kind of team are we in?” And you’ve used the terms moving from project-led to product-led functions. Can you help our listeners understand, how do they know what kind of team they’re in?

Janna [00:02:04] Yeah, absolutely, and I like those terms because they help denote the difference between the type of team that you’re in. So a product-led team is very much looking at the future of the product as a whole, and the reality of a product is that it doesn’t have a final state that’s known, right? When you’re building a product, you’re building into uncharted territory. And so the team that’s building towards that product, who’s building that product, needs to have an attitude that’s set for that. They need to understand that they don’t have all the answers and they don’t know all the next steps, but they can work out the information they do have in front of them and can work together to experiment and to find the best path forward for them based on the resources they have.

Janna [00:02:40] Whereas a project-led team is generally focused very much in terms of set projects, and a project should have a final state. You should have a known scope and time and cost, and that’s fine if you’ve got a final time, scope, and costs for things. But the problem comes when you start trying to apply a project mindset to something as long-term and as huge scale as a product company. Because what tends to happen is that you can’t think that big. You don’t know what the final state of your product is going to be and so you get stuck in this very, very tight mindset of being project-led trying to constrain yourself down to, “who’s going to be working on what and when is it coming out and what feature needs to be built next to meet that scope,” when the reality is you don’t know what the scope actually is down the line anyways.

Paul [00:03:27] Yeah, that uncertainty of product road mapping makes shareholders and boardrooms a little uncomfortable, right?

Janna [00:03:33] Absolutely, yeah.

Paul [00:03:34] Yes. I mean, what that means for product leaders in the organization, then, is sort of this paradox of being hired to do one thing, but then being asked to perform another way and this can cause people to feel trapped at times. How can people address that conflict or that sort of inner disconnect?

Janna [00:03:53] Right? Yeah. And so many product people have been in that position. I’ve been in that position myself where you end up in a role as a product person and you’re excited about the product and what it could be. But in reality, the execs of the company, the business itself is very much drawn to this expectation that you’re going to stand at the beginning of the year and tell them what you’re going to go deliver and then go deliver it, which just is unachievable. You know, it’s fine if you are happy to lock down and, you know, spend the time in project management to decide what’s going to happen. But almost certainly you’re going to be giving up so much more by doing so. You know, leaner teams tend to deliver and outperform project-led teams by a huge margin.

Janna [00:04:34] And so if you’re in this position, it can be really tough. I really empathize with anybody who’s been stuck in this position, and there are quite a lot of them. There are things that can be done, though, and it really does depend on your position, right? Because sometimes it depends on what the exec team is actually looking to do. Do they actually know that they’re being project-led? Do they know that they’re stuck in this mindset and is it something that they’re looking to address? If so, you know you got management buy-in. You actually have some free space to operate and to start making some changes. Or is this a way that they intentionally build their company and what they want? In which case you sometimes might actually be in the wrong place and need to move on.

Sean [00:05:13] This reminds me of Simon Sinek’s recent book, The Infinite Game, right, and what game are we playing? And there’s infinite games and there’s finite games and product, really, if you’re trying to build something that’s strategic in nature and is going to build relationships with your consumers, then you have to figure out how you’re going to adapt it, which means that you can’t be playing this finite sort of project mindset, as you’re calling it. I love that language. You have to think about, how can you build creativity into the process? And that’s what’s missing, right?

Janna [00:05:42] And actually, that’s really key. I like that, the difference between the finite game of the infinite game. I’ll take a look at that book. The word process, that was actually really key here, because that’s what’s actually really magic about a product-led team is that they’ve got a process that allows them to deal with the uncertainty, that messiness that they’re approaching, right? It’s not that they know all the steps that they’re going to take, it’s that they are prepared as a team to deal with whatever comes their way. And some of the magical things that they’re able to do are actually quite simple if you boil it down. If you think about it, a process is no different than a product. Like product is something, you know, as we know from Lean, that you can measure and you can learn from and you can build and iterate upon and improve. Well, a process is similar, right. You have a starting point for your process and you can measure it and you can learn and you can iterate on it, and you can improve that process over time. And ideally, you should have a team that is willing to adapt its processes based on what’s happening out in front of it. And, you know, a team that is readily adaptable in that way is, you know, ready to take on whatever the market throws at it, whatever the world throws at it.

Sean [00:06:47] Yeah. And you know, we’ve got to balance this possibility versus predictability as product leaders every day, right? So another question that Paul and I had about exactly this concept is around titles, like the title Product Owner or Product Manager or Product Leader. What do you think about titles in this scrum space, like for product owners?

Janna [00:07:09] Honestly, titles, I don’t think make a huge difference. The thing is, is that if you start taking a look at titles across a wide enough sample set, right, you start taking a look at titles globally, you start getting huge differences amongst what people actually consider a product manager versus a product owner. And to me, it really matters what you actually did rather than the title itself, because I’ve seen people who are billed as product owners, but they’re actually doing product management. I’ve seen people who are billed as product managers, but they’re actually closer to what classically you consider a product owner. I’ve seen people who are billed as something entirely different, like a delivery manager or customer success or whatever, and they’re doing classic product management, or people called product managers and they’re not doing anything like product management at all.

Janna [00:07:56] So really, the title doesn’t matter all that much, and it actually differs from region to region as well and level of company as well. Some companies like to have both. Some companies like to have neither. I wouldn’t hang your hat too much up on that. And something that I’ve heard is whenever you’re applying for a role for product manager, product owner, whatever it is, don’t spend too much time getting hung up on what the title is going to be because that’s negotiable when you get in there anyway, unless the company’s got some really fixed idea about what they call their product people. But what you should do is take a look at what the job description says. What that’s telling you is what problem the company is trying to solve. And from there, you should be able to decide as to whether you can solve their problems and you should be able to craft your answer, your CV, your cover letter to tell them how you are going to solve their problems. And when you get in there, you should be able to hopefully solve their problems. And so your past background as a product person, whether you’ve got one title or the other, shouldn’t stop you from moving across from one to the other, and you shouldn’t get tied up on what the titles are. You know, it’s really more about what you’re actually doing as a product person. Collect those experiences and use those as you move forward with your career.

Paul [00:09:03] Yeah. You know, regardless of title, the product leaders and the product community, in general, are really starting to gain more traction within boardrooms, within general business functions, within firms. You started alluding to a moment ago when you talked about sort of size of company or type of space. As product leaders, we can start to influence and begin to not only adapt to the company, but help the company adapt to our skillset and the mindset that we bring to the table. You started talking about it about a few minutes ago, but I’m wondering, can you elaborate a bit more on how can a product leader begin to both adapt themselves to the organization and help the organization understand, you know, what they’re leaving on the table by not using product leaders to their full potential?

Janna [00:09:42] Right? Yeah. So with something like that, it’s how long is a piece of string? Because when you’re a product leader coming into a company, oftentimes you come in and you find out that you are the first product leader, particularly people of my cohort, and we’re coming in and finding out this company has been sometimes making money by mistake and hasn’t been product-lead. It doesn’t have a product lead bone in its body. And so you are sitting here, you know, having to lead this transformation, whether they’re calling it a transformation or not, you’re having to lead a change in their mindset and how they work. And oftentimes they’re hiring a product person because they know that everyone else has hired a product person and it’s worked for them and they haven’t necessarily always followed a good discipline around how to manage an ongoing product and an ongoing set of customers and everything like that.

Janna [00:10:28] And so product leaders can be hugely influential and hugely powerful with helping a company gain its status as a market leader, as well as maintain its status as a market leader. Because, you know, getting a foothold and keeping a foothold in any market can be hugely difficult and competitive. And it’s the product companies who are the ones who are able to make sure that they are creating the best experiences and solving the problems for the widest and the right customers, of course, and for the widest part of that market and pricing themselves properly, all of which are part of the product function. These are hugely transformative for companies if they are able to get the edge over their competitors.

Janna [00:11:04] But a lot of it comes down to how receptive the rest of the business is to it. And sometimes the business is totally receptive. A lot of times a lot of these companies have survived without having a product team because oftentimes founders themselves are product people. They just never call themselves that because they’re too busy doing everything else, but they, in their heart, have the product mindset anyways. A lot of the stuff around product management is actually pretty intuitive if you think about it. You know, this idea of doing tests before you lob all your money at it and checking whether it works first, right? It doesn’t sound like rocket science. It does become considerably more difficult and therefore expensive as you try to scale it, which is where product leaders and your product ops director and that sort of scale of talent is really going to help make a difference to your business as you start bringing in more and more product people to help guide the huge group of engineers and designers, and, you know, everything else that you’re throwing out the problems that you found in the market.

Paul [00:12:00] Yeah, it also becomes a lot more expensive the further committed you are to the solution that you’ve chosen. It’s very easy to tear up a post-it note on a whiteboard. When the idea is still nascent, you can change direction, but once you have pixels on a screen and code committed, it becomes not just incrementally more expensive, but exponentially the further down the line that you get to change things or shift direction.

Janna [00:12:20] Well, yeah, exactly. Something I always point out with people is there’s so much written about greenfield product management. You know, how to get from zero to a million, how to get product-market fit, how to get your first 10 customers, or you know, how to get traction and that sort of thing. Medium is basically built for this stuff, right? Reddit, all these different resources, you’ve got tons and tons of people talking about this stuff. Then there’s very little talking about how to get those next stages right, 10 to 100, 100 to, you know, a million, that sort of thing. And what tends to happen is no one likes talking about this stuff because it gets more difficult and there’s fewer people there.

Janna [00:12:55] But very few product managers actually build greenfield products, right? When you get a new job as a product manager, you don’t get to start something from scratch. You only get to start something from scratch if you’re the founder. Most product managers adopt someone else’s pile of JIRA crud, right? Like, it’s a pile of stuff that’s been built and a pile of backlog stuff that’s been thought of, and you as a product manager are basically told like, “here, help us do something with this.” And you’ve got tech dirt and you’ve got constraints and you got customer commitments that have been made and you’ve got existing politics that you’ve just walked into and all these different things that are stopping you from being able to just pivot tomorrow. Even if pivoting was the right thing to do, it would be really difficult to figure out that that was the right thing to do and even more difficult to bring the company along on this journey to go do so. And so a lot of times, you end up just sort of following the path that was already set on, even though it might not be the best path anyways.

Paul [00:13:49] Yeah, I want to sort of tie this back to where we were going before, too, with the incentives of titles or just type of company versus process and especially the thought of process as a product, I love that. Agile and Scrum processes are, you know, the industry standard. I think nobody, you know, would argue against the value of the system or the process itself. But at a far enough iterated level, it becomes disincentivized because being truly agile means, you know, less predictability for your shareholders, for investors. There’s that lack of certainty that people need to have: “when is the launch date?” And I think we start to feel this pull of, what is the process really? Am I really agile? Am I really a product owner in a scrum environment or has this become something else? And is that bad?

Janna [00:14:35] I think one of the problems that people confuse here when people are asking about predictability for the shareholders, right, there’s predictability about which features are going to come out and when. But honestly, the people who are investing in your company are watching your stocks, right, predictability at that level. They don’t care about the individual features. They want to know that the right numbers are going up and to the right. They want to know that the company is hitting its overall targets and, you know, agile vs. waterfall vs. whatever else isn’t necessarily the thing that’s going to make the difference there. Agile is just a means to the end, really.

Janna [00:15:08] So I think product managers get stuck in a little bit of a trap where the execs try to lock down everything and try to say, “You know, what is actually going to be happening? What are you actually doing to solve these problems?” When in reality, it’s actually not helping their cause. The way that I think about things is that agile sprints are really there to help make sure that you can build something and iterate at the end of that sprint, right? But the bigger piece, really, that the product manager is looking at is something more on the quarter by quarter basis, right? You’re looking more at the big numbers to hit, the objectives, the success metrics, that sort of thing. Are they going up in the right direction? Are they going down in the right direction? What are you trying to do for the business? And that’s really what the execs should really be focused on and worried about.

Janna [00:15:53] And this is where OKRs come in. This is why OKRs can be so powerful because you have your execs setting your top-level objectives. They’re able to say, “for this quarter, it’s important to us that we really increase our market share by X or decrease our churn by X,” or whatever that sort of top-level metric is that’s been determined that’s going to help make the company successful. And, ideally, in a product-led company, the team would be given space to go find ways of solving that. Now the thing is, is that by space, it means that they’re given enough space to go do as many experiments, launch as many features or things that they need to do to solve that problem. Now, it doesn’t matter exactly which features they’re going to launch or which features they take away, or whether they do five features or 10 features, or no features. It’s all about how many experiments they can run that quarter.

Janna [00:16:42] So all that they’re doing is saying, “You want us to go increase revenue by X dollars, by X percent, whatever. Sure, give us a quarter and this quarter we’ll run as many experiments as we can. It might be 50, it might be 20, it might be 60. Depends on how big our team is. Depends on many different factors that we don’t know yet. But we’ll run as many experiments as we can and we guarantee that by the end of this period, almost certainly this number is going to go up and to the right. We’re going to increase that revenue figure.” And no one actually cares as to what those experiments are. Some are going to fail and some are going to pass.

Janna [00:17:14] And this is no different than what other teams are doing. So put it this way: your VP sales aren’t being asked for an exact date and dollar amount on who’s going to be buying what package on what day. They don’t know that, and they don’t try to give you that. No one is asking for that level of certainty because it’s a bit silly to ask them for that. What they are asking for is budget, and therefore freedom, to go experiment for the quarter. Right. So if they’re saying, “we want one quarter,” let’s say it costs a million dollars for the year, so a quarter-million dollars for the quarter. They want to take those quarter-million dollars and invest it in 10 salespeople and those 10 salespeople are going to run as many experiments as they can for that quarter in order to increase the numbers. And by experiments, I mean phone calls or emails or whatever they do these days. And some experiments are going to fail and some experiments are going to pass. Right. They’re going to get hung up on and they’re going to get turned away, but some are going to pass and they’re going to get some people who actually end up going to through pipeline and they buy the product at the end of the quarter.

Janna [00:18:12] So they don’t know who’s going to buy, but they do know that if they keep hitting the phones, people are going to buy and the numbers keep going up. And this has worked year on year on year for decades now, and no one has ever given any qualms to the sales team for not telling them who’s going to buy, just that they’re going to put the effort into perfecting a process by which they can come to this money at the end of the quarter or period. We’re not asking for any more freedom than that. Put it this way, marketing has the same thing. Have you ever heard this one: half your ad dollars are wasted, you just don’t know which half. Marketing is one big experiment. They’re given some freedom, some budget, to go test things out, and they know that some things are going to fail, some things are not going to fail. And at the end of the quarter, hopefully, they’re going to have some return on investment that they can show. But they’re not told, you know, if you spend this dollar, this lead is going to come in.

Janna [00:19:00] So, I mean, agile is, of course, a means to the end. You need to have the agile so you can quickly do all the experiments, but you don’t need to be having to tell people exactly what things are going into your agile sprints in order to report that back up to tell everybody what things are going to happen and when. That does not help the cause for anybody. So for anybody who is being asked to give certainty on what’s being delivered and when in order to please the people who are doing budgeting or trying to nail down the numbers for the year, push back on it and point out that that doesn’t work this way for the rest of the business, so why should it work this way for product?

Sean [00:19:34] Yeah. What we’re talking about here is what I call the difference between leadership and management. And if you want creativity from your team and your people, you want to think about it from a leadership perspective, and you’ve got to give a certain amount of trust and allow for more experimentation and more freedom in terms of control. Which leads me to my next question. You have become somewhat famous for your discussions around timelines and how timeline roadmaps suck, and it’s sort of the foundation of your company, ProdPad. One of the things that fascinates me about your approach is around assumptions because I’m a big believer in everything you say about how objectively prioritizing your roadmap is pretty much impossible, right? And it’s impossible because we’re making a whole bunch of assumptions, and I’d like to hear your thoughts on those assumptions.

Janna [00:20:22] Yeah, absolutely. So some background: I used to do a timeline roadmap. I used to make a version of my roadmap that looked just like a beautiful, colorful Gantt chart type thing, and I would plug in all the features I was building and I would take it and I would show it to my boss and I would get a little pat on the head and I’d be told to go build it. And I was never able to ever build everything that was on the roadmap, but I just figured that was me and my delivery chops and not so much my, you know, project management chops or the roadmap itself. And it wasn’t until I realized that I also needed something to help me manage this complex roadmap that I started building it into what became ProdPad. The early version of ProdPad actually did have a timeline roadmap. But what I actually realized was showing it to other product people, one of the first requests was everyone asked to take everything from that first month. A month later, the first request was, “Can I push everything over by a month?”.

Janna [00:21:16] Everyone wanted to push everything over by a month or so because everyone had missed even their first month. And so had we listened to the customers, we would have just had like some multi-select thing where you could pick up everything in the first month and drag it over and drop it by a month. But we asked the five whys. We really started figuring out why people weren’t able to update the roadmaps or why people weren’t able to hit the dates on the roadmaps, and we figured out that the format of the roadmap itself was just holding people back. And so we started trying to figure out what the purpose of a roadmap was. Because if this wasn’t working, like if no one was delivering on the roadmap and this format wasn’t working, then what is a roadmap? And really a roadmap is a way to lay out the assumptions that you were making about the problems that are coming up so that you can discuss them with other people on your team.

Janna [00:22:01] Right. I like to call the roadmap a prototype, but for your strategy. Just as if you were a designer. If you’ve ever been in a design role, if you’ve ever played around with designs, you don’t take your design right out of your head, plunk it down in a final design file, and then send that off to engineering to be shipped and delivered, because almost certainly it’s going to be junk. Customers are going to look at it and say, this doesn’t work, and then you spent all that time and engineering. It’s a bit wasteful. What you do is you sketch it out on a piece of paper, right? You put some boxes within boxes, buttons, it’s a basic copy. And then you show that piece of paper or that quick mockup, wherever it is, to a customer or teammate and they give you feedback and they tell you, “maybe you should move that button here, or maybe you should add some copy here.” And you take that feedback on board and you improve your prototype, you improve your interface and your first prototype gets thrown out. You throw out that piece of paper and the value isn’t in the prototype.

Janna [00:22:54] The value is in the conversations that the prototype allows you to have. And by doing this over and over and over again, having these conversations, your design goes from flimsy, something that you just made up, to something much more robust that’s more likely to solve the problems that you’d outlined. And this seems all really intuitive, anybody who’s done design work at all, you’ve done this process over and over, really intuitively. Road-mapping is just the same process, but for your strategy, so you take it up a level and you’re thinking about it much more at the product’s strategic level. So you’re using a roadmap to say, “Well, here are the big steps that I think we could take. We could go here then here there here. We have this problem than this problem then that problem.” You lay that out in your roadmap and then you share it with somebody. And they might say, “Hmm, I thought we had this problem, then that problem than the other problem.” Well hey, it’s good that we had this conversation now. We’ve identified a whole new other problem, and we’ve changed the order here. Great. So you update your roadmap based on this conversation.

Janna [00:23:49] If you keep having these conversations with people on your team, you’ll identify new problems, you’ll identify nuances around how you might order things. And what you’re actually doing is you are validating your assumptions about your strategy and what you’ve then got is you’re taking it from a flimsy strategy, which is one that no one was talking about and that was just, you know, flopped down on the paper as the first thought, to something that’s much more robust and so your roadmap shouldn’t be just a list of features and deadlines and due dates. It should be a way to outline your assumptions about the big strategic steps that has been checked and collaborated on with different people on your team, even with customers, with anybody who will talk to you about it, so that you can move it from being flimsy to much more robust.

Paul [00:24:33] Yeah. It comes back to the paradox of, you know, predictability is risk, and it’s safe, it’s comfortable. It feels nice to have dates on a roadmap, but you know, it’s almost like investing in cash. Cash is a super-safe investment, but if that’s all you’re invested in, you’re never going to keep up with inflation and you’re going to lose out in the long run. So by being super safe, you can actually introduce risk to your system. But it feels good in the moment because a dollar is a dollar is a dollar, a date is a date is a date. And you can say with certainty that, “yes, my roadmap says I will hit this thing on this date.” But then when the date comes and goes, you don’t have a backup plan. So you know, one of the conversations is interesting to me is actually introducing risk, a healthy risk to the process, so that there is a way for product leaders to have a conversation about experimentations failing and that being OK. In large organizations and very mature products, it becomes sort of difficult to even entertain the notion of bringing risk into the system because, you know, it goes back to disruptive innovation and the innovator’s dilemma. Do we want to disrupt ourselves? Do we want to bring change to the system?

Paul [00:25:42] As product leaders, it’s not just, you know, a benefit or, you know, something exciting or novel. That is the job, bringing that ideation and bringing that creativity to the team. Because the delivery team just wants to ship a product, the business team just wants to be able to communicate business goals and predict ROI and the up and to the right numbers. As product leaders, you know, it’s our duty, it’s our responsibility within the organization to be able to bring healthy experimentation mindset to teams where they’re incentivized to do the exact opposite.

Janna [00:26:15] Yeah, and that’s actually a really good analogy about predictability versus risk. Because, you know, if you think about it, when you’re laying out something on a roadmap, no matter how you’re looking at it, the key thing to remember is that you’re not safe, right? You’re not staying in one space. If you’re building a project, if you’re building a house, for example, right. You’re safe in the knowledge that no one else is going to come in and try to build a house on that same plot. Probably, right? So things can get pushed and other things like that can happen and so you can spend the time making sure that you’ve got all the project planning upfront to reduce the risk and make sure that everything happens in a nice, steady project timeline sort of way, and that there’s no wastage with the actual project timelines so that you get to completion for that particular thing.

Janna [00:27:00] When you’re talking about the scale of a product, well, you’re talking about this in the context of an entire marketplace where, by the time you actually build something, you don’t even know that that thing’s actually going to be relevant anymore. Right. You’ve got people who are standing at the beginning of a year and trying to predict what quarter they’re going to launch something in that’s three quarters from now. And the reality is they don’t know how big their team is going to be three quarters from now, let alone how fast they’re able to deliver. And one is the product of the other. They don’t know that their market’s going to be in the same place anymore. They don’t know that there’s not going to be some upheaval, that there’s not going to be some new competitor.

Janna [00:27:36] And so what they’re actually doing is what looks like it’s nice and safe, like, “yeah, just deliver all the stuff.” But they’re not thinking about what’s happening all around them with the market and the competitors and with everything else that is almost certainly going to come in and disrupt this. And I think that might be one of the problems with these companies that are built for predictability is that they are sitting on their laurels, right? They’ve got bags and bags of cash. They’re happily growing at zero point zero one percent per year, and that looks great. Their investors are super happy with this because it’s predictable, and they can safely invest in this and know that it’s going to go up by another zero point zero one percent next year and their money goes up. Great.

Janna [00:28:16] But these are the giants that are being nipped at more and more and more by every startup, every competitor who’s out there, right? Take FinTech. Take E-commerce, take any giant field right now, there’s no space that safe. Where it was maybe 20 years ago, right now, it’s just being taken down by every possible angle. And what competitors are doing is they’re taking out the tasty spots. They’re now able to say, “Let’s not build the whole giant, let’s just build the profitable parts and find ways around it,” even if it’s not even legal, right? You find companies who are finding their way around banking laws and hotel laws and taxi laws and other things like this and totally disrupting entire spaces that you would have thought were safe. And you’re not safe, even as a giant with huge banks of cash, with laws protecting you. Startups are coming for your space if you’ve got market share, if you’ve got money in that space.

Sean [00:29:13] And problems to solve. For sure. Well, that’s awesome. So thank you for spending all this time with us. We have a couple more questions for you and then we’ll get wrapped up. One is around innovation, and I just like to collect people’s thoughts on innovation. How do you define it? What does innovation mean to you, Janna?

Janna [00:29:30] Oh, I love that question. So I guess I would define innovation as the ability to identify opportunities and create solutions, create ways to tackle opportunities.

Paul [00:29:43] And the last question, you know, as we part ways and send our listeners off, just something to think about, what would you recommend is something to read? What’s a book that you’ve encountered recently that you think a product leader might benefit from picking up?

Janna [00:29:56] Oh, good one. Actually, I’ve got one on my desk right now that I’ve just been reading now: Continuous Discovery Habits by Teresa Torres. I wasn’t expecting the book shout-out, but I just happened to have this on my desk and it is absolutely a good one, highly recommended for, actually, teams of all sizes. Because, you know, if you are looking to innovate, one of the core principles behind that is the ability to be able to continuously discover, right, to understand the problems that are out there and to be able to react to them and get your team involved with that process.

Paul [00:30:27] Teresa is a great thinker, great recommendation,

Sean [00:30:29] She’s a great thinker. She’s been on our podcast. We’ll post a link to that. I also noticed she was on your podcast, maybe a couple of times.

Janna [00:30:36] She was, yeah.

Paul [00:30:37] Excellent.

Sean [00:30:38] Thank you for your time, Janna.

Paul [00:30:39] Thanks, Janna.

Janna [00:30:40] Absolutely. Thanks so much for having me.

Paul [00:30:42] Cheers.

Paul [00:30:45] Well that’s it for today. In line with our goals of transparency and listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get, so please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world just like you’re doing. Thanks, everyone. We’ll see you next episode.