A few weeks back, I spoke to Jason Knight for The Lean B2B Podcast. We talked about customer discovery, the enterprise, product/market fit, startups, and B2B product management.
You can watch the full interview below, or access it on iTunes, Google, or Spotify.
Interview Transcript
Etienne Garbugli: My guest today is Jason Knight. Jason is Product Director at DueDil a company offering real-time insights on SMEs to financial services providers. Jason is also the host of the One Knight in Product Podcast, where he speaks to great product leaders around the industry. Jason has been working in product roles at enterprises or selling to enterprises his whole career. He’s also one of the best follows on product management on Twitter.
Jason, welcome to the podcast.
Jason Knight: Thank you very much for having me, and thank you very much for the kind intro as well.
Etienne Garbugli: Maybe as a first question, why B2B? Or why enterprise? What initially attracted you to the space and what has kept you there all these years?
Jason Knight: Well, there’s a number of ways I can answer that question. I think, as with a lot of product people, you end up happening upon your first role. Like, if you asked me to look back, I could probably retrofit choosing B2B. But actually, B2B is just where I landed. I’ll also say that for a large number of years, I mean, I’ve been around for a while, it’s not always been a product role.
I’ve always been working in technology, and originally, market research, selling to big companies to try and help develop solutions to solve their problems and get insights for them. But for a long time, I was working very much on the development side. I was working as an analyst for a bit, moving up into development, and then moving into team leadership.
One of the things that really becomes clear whenever you’re in any leadership role is you’re automatically becoming a bit more “product-y”. And I’m going to back that up because you can’t just care about how you build things anymore when you get into team leadership. You start having to deal with stakeholders, deal with clients, deal with everyone else that you have to deal with.
I think it was a real slow segue from developing the stuff into deciding what to develop and working out what to develop. That took a few years. Back in the day, it was very much also very waterfall-y, very slow. The company I worked for was one of these archetypal big 100-year-old companies that had everything that you’d see in like The Innovator’s Dilemma and stuff like that. It was not a very agile startup or anything like that.
But then back in 2017, we had a new CTO come in. He brought with him a copy of The Lean Startup and started waving it around and saying, “Hey, this is pretty cool. We should start doing stuff like this.”
Now, it’s very difficult to do that sort of thing in a big enterprise, but I read the book and I was like, “Wow, this makes a lot of sense.” And that then started the push much more into actual product management. And then, eventually, out of the enterprise I was working for and into startups, scale-ups, still working B2B because, to be honest, that’s where all my experience was.
It was going to be a very big conceptual leap for me to go from a 100-year-old market research company into some social media app for dogs or something like that. That wasn’t a really feasible move. So, moving into startups and scale-ups that are serving enterprises, and in some cases, the types of company that I used to work for, and in some cases, just different types of companies.
I think that happened naturally as well; I’ve never looked back. I think the startup and scale-up world offered a lot more and resonated a lot more with me.
Etienne Garbugli: So, you’re saying you don’t like dogs?
Jason Knight: I don’t like what? Big companies?
Etienne Garbugli: Dogs.
Jason Knight: Oh, I love dogs. I would love to have a dog but I’m not allowed a dog. My wife says that I can’t have a dog because, A, we have a cat, and, B, she has this sneaking suspicion that while I’m doing all my podcast recordings, she’ll end up walking the dog. So, when I retire one day, maybe I’ll be able to get a dog.
Etienne Garbugli: Future plans; perfect. We’re often talking about early-stage companies on the podcast. But let’s start to cover what happens once a product company finds product-market fit.
So, if you’re joining a company or working on an enterprise product, what would tell you that a company’s product has product-market fit?
Jason Knight: Well, obviously, if a company has clients, that’s a good start. But it’s not just as simple as that. I think and I’ve seen there’s been companies that I’ve talked to in the past or even I’ve worked with that have kind of happened upon what they think is product-market fit because they’ve got a few foundational clients. And if you think of things like Crossing the Chasm, they’ve got the early adopters; people that will buy just about anything.
I think you talk about this a bit in your book as well. In some cases, they’re basically rounding errors on their accounts to get access to a possibly good solution. I think the thing is that some of these people will buy pretty much anything, to be honest.
I think one of the warning signs for me is that if you go into a company, or if you’re interviewing with a company, or if you get your Spidey sense around a company, and you sit down and see that 35%, 40%, or more of the revenue is coming from one client, you might start to consider that they don’t necessarily not have product-market fit, they could have, but it’s not guaranteed anymore. Because so much of the money that they’re getting in is being pulled in from a very small number of users, effectively.
And that means that this little company can start to get bullied around. And if the company gets bullied around, then you start to end up building additional extra stuff for your big bear clients. And again, they’re paying the money. If they walk out, maybe people get fired. So, you probably end up having to do some of that work against your will, to some extent.
I think that’s the thing that I really look out for. There’s a couple of things really, one of which is what I just said. The other is, if there’s a really strong services arm from the beginning, that’s not necessarily a problem, but it does potentially imply that the product that they have isn’t strong enough to stand on its own and that the company is going to have difficulty scaling.
Etienne Garbugli: So, can the product fly on its own without the need for the services versus the services just adding on top of the revenue?
Jason Knight: This is the whole Wizard of Oz thing, which is a very good experimentation technique. You can sit there and basically say, “Hey, let’s do it manually for a bit, and maybe that’ll work out.”
I was talking to David Bland about that, and he was saying, “Well, sometimes that’s never a problem.” If you get to a point where that’s actually sustainable, the amount of work you have to do to sustain that works out for you, and the unit economics are fine, then Godspeed. But if you’re in a position where you’re so reliant on that Wizard of Oz person behind the curtain to keep the product moving and to scale, and every single new client becomes additional people that you need to hire, again, you start to be concerned that this is not something that could sustain itself.
And you might, again, consider that you don’t really have product-market fit for your, say, SaaS product. You may have more product-market fit in a broader sense of the term, like if you include services and all the manual labor that you have to put in. But you’re definitely going to have trouble scaling it.
Etienne Garbugli: Okay. So, if we assume that the company has product-market fit, what would you recommend that the company does afterwards? So, it just figured out, say, we have sufficient product-market fit; what next?
Jason Knight: I guess a lot of this depends on how you got to the product-market fit in the first place. If you’ve, frankly, happened upon it, maybe from some foundational clients, you’ve got to where you’ve got, you’ve managed to have enough discipline to build something that lots of people want, but you just happen to have that embedded with a few clients first, then you’re in a good spot. You’ve basically been doing a bit of product thinking to start with, and you probably got a good platform to build off of.
If you’ve got to a point where you’ve kind of got product-market fit, but not really because it’s so super-optimized for your foundational clients, that’s where I think you really need to start doing some proper product thinking. For example, if you’ve been in a situation where maybe the CEO or the rest of the leadership team have been proxy product people; they’ve been doing this stuff themselves, well, that’s fine. But they’re going to have to hand over the reins and start to listen to customers and listen to users.
And the easiest way for them to do that is to get proper product people and to do proper product stuff. Start the discovery flywheel going; start to understand things that not just the clients that they’re talking to already want, but that the wider market wants. Start getting ahead of trends; start getting ahead of the curve.
Because all the time you’re being driven by the demands that you see in front of you, and that implies a sales-led approach, then you’re not necessarily going to be able to make the big impact that you want to make because you’re too busy chasing your tail around the smaller stuff. So, trying to get ahead of the curve, applying that good product thinking, if you weren’t doing bigger, wider user research and discovery, then start doing that. Pull in some kind of product team. It doesn’t have to be a big one to start with. Then start turning the product flywheel and start making good decisions rather than everything being based on what you thought you knew.
Etienne Garbugli: Speaking about making good decisions, as a product manager or product director, in your case, working on enterprise products, who are you building for? How do you shape the product when there are many different stakeholders at every client? They might not all be in agreement. The customer may not be the end-user. So, who are you building the product for and how do you figure that out?
Jason Knight: Well, you’re building it for both. And when I say both, I mean, the users and the buyers because they tend to be different, especially when you’re selling into the enterprise. If I’m selling to the enterprise, I’m presumably going for a six-month-long sales cycle, talking through layers of procurement, loads of different internal stakeholders that have to align around my product, all the vested interest and politics that that implies as well at the other side. So, I know this is a process.
And you’ve got to impress those people to get them to buy. At the same time, those people, in many cases, are not actually going to be the users of your products and they’re never actually going to see it.
So, they care a lot about the strategic and the enablement stuff: how you can make them look good, the macro-level cost efficiencies, the monitoring that they can do of their staff, whatever it is that they care about within the confines of what your product does. You have to get past that to sell it to them in the first place and get that first 50 or 100 grand deal, or however you sell it.
Once you’re in, of course, these people still care, but you’ve also got the additional wrinkles. You’ve now got the people using the platform as well. So, it has to be delightful, just like any other platform for any other type of person. But these people aren’t the ones who are actually signing the check.
So, you still need to keep an eye on the people that are actually signing those checks. Because come renewal time, you need to be able to show that there’s a strategic direction that you can take these people along on a journey and enable things constantly going forward that enables them to do things that they care about, either because they’ve told you that they care about the strategic, macro-level trends, industry trends, whatever’s going on.
You also need to make sure that you’ve not got loads of users moaning to these people internally that this solution is absolutely terrible, it doesn’t do half the stuff, and that they have to sign up for three other solutions and remember three other logins just do the bits that your product doesn’t do.
However, my solution to that last part is always to get an Excel export into the earliest spin you can with any B2B product. That might sound stupid, but if there’s going to be things that your product doesn’t do, the easiest thing, rather than keep chasing your tail and just sitting there trying to work out ways to do this, or adding layers of services on top to just try and desperately keep hold of these clients, give them an Excel export. They can dump their stuff into Excel if they need to, make the pie chart that they need to, and maybe that’ll keep them happy. Rather than just trying to jump on every single fire for every single misuse case or every single potential renewal requires to keep you going.
Etienne Garbugli: In the example that you were referring to or thinking about, you mentioned procurement. Would you categorize procurement as your buyer? Or would the buyer, in that case, be the functional leader that might have initiated the purchase? Or would they both be still important as you’re building out this solution? Or does just procurement get out of the way afterwards?
Jason Knight: I think that the procurement team is not really the buyer, but you absolutely have to get past them. There are going to be regulatory concerns, potentially, depending on the industry. There are going to be potentially cost control concerns, of course. There are a lot of things that they care about.
They’re actually not at all the thing that your product is living or dying on the merits of. No one’s putting into their marketing materials, “We’re ISO-whatever compliant.” You might have it as a little badge down the bottom, but it’s not your core value proposition. But that is something that these procurement teams will very much care about.
And this is where the challenge comes with things like product-led growth, which is, obviously, a big trend and something that I think that we should try and use as much as we can. But at the same time, you’re not going to get a bunch of procurement people to just say, “Yeah, just let the CDO or the CIO just pay on a credit card, and then just buy a bunch of licenses for people.” That, obviously, can happen at some companies, but in big enterprises, they’re very unlikely to buy this whole new global system for all of their different offices on a credit card and just let everyone self-onboard.
Again, I think product-led growth is a really interesting trend, and we should try to lean on aspects of it as much as possible. But this procurement process is a constant theme in lots of big enterprise and B2B sales.
Etienne Garbugli: Okay. So, let’s go in that direction then. You’re mentioning product-led growth, where the product is the main thing that attracts people and people are self-signing into the product, oftentimes, self-onboarding. In that case, how do you see product-led growth or PLG impacting enterprise products moving forward? How do you see that relationship evolving moving forward?
Jason Knight: I think that, in some cases, you actually can get this self-sign up thing going. If you’ve got a product that is aimed at the top end, aimed at the enterprise, that has some functionality that is potentially useful for smaller businesses, you could have a long tail that you could PLG as much as you want. Maybe even give them self-sign up, self-onboarding, and just have a real hands-off experience.
That’s not something that I think a lot of enterprises necessarily want, or that would resonate with them. But certainly, for that long tail, I think that you can try to do as much of that as possible.
For me, where product-led growth really starts to shine when you start thinking about what you need to do to make your product attractive and be able to be self-signed up to, to be able to be self-onboarded to, it’s all about the quality of experience of the tool. So, if you’re in a situation where you’ve got a rubbish UI, rubbish flow, everything’s inefficient, everything’s confusing—maybe we’ve all seen the stupid memes online with “Apple did this and Google did this. And your app looks like this, and it’s got 5,000 buttons or whatever.”
Now, I do think, for example, that there are many Apple and Google products that have terrible UIs as well, but I get the point. It’s really easy to overcomplicate a SaaS tool. I don’t think that everything can just be a “Smash Here” button because some tools legitimately do complicated things.
On the other hand, we shouldn’t use the fact that salespeople are going in and smoothing over our experience, and CS people and training people are going in to smooth over the onboarding, as an excuse to not do some of that good UX/UI work to make sure that the products that we deliver to people are actually good for them to use.
Because it’s not like the old days where you had to be an expert to get access to a certain system; everyone’s got access to everything these days. The vast majority of people know how to use apps and are used to signing into things and doing things in a digital fashion. So, we can’t sit there and hide behind salespeople, or hide behind service people anymore, and use that as an excuse. We should bring as many of the product-led growth principles about onboarding, simplicity, making our tools as delightful to use as possible. And, of course, that, potentially, has the side effect that you could one day offer a free trial, or you could offer self-sign up, or even sooner if you have that long tail. But, of course, the cliche about product-led growth for, say, enterprise products is that you definitely don’t want people logging into your enterprise product because it looks awful, it’s hard to use, difficult to get value out of, and people aren’t going to buy it if they do that. So, you have to obscure it. I think that’s something that has to go away.
Etienne Garbugli: So, do you think it might be a better approach to get the DR enterprises to discover the initial value, and then the company is probably better off to transition to an actual sales process and layer that on top of the initial assessment of the product?
Jason Knight: Yeah, probably. It’s definitely a thing to think about. For example, let’s imagine we have an API product. There’s a lot to be said for just having a self-sign up, 20 calls, sandbox-account type thing, which enables you to get some value out of an API without talking to anyone. Now, not everyone does that.
I think that when you’re talking about data products, which, obviously, power a lot of the big data products or things that combine other data sources, there’s a lot of concern, in some cases, around, if they get logins and they get access, then they can just start looking at stuff. And so much of the value of our product is actually the data that we serve, and they could just get a bunch of free accounts and copy.
Now, of course, if your product is that easy to copy, then you’re probably in trouble anyway. But at the same time, it’s not a completely invalid concern. You need to be able to protect your intellectual property and be able to hive off enough functionality that people can legitimately come in and look and get value and see the joy that they can get from using your platform without just opening the kimono and just letting them have everything. You want them to actually buy afterwards, right? Not just spider an entire 5,000 new accounts that they just open up and then just download everything and then they’re gone. That’s not good for anyone.
Etienne Garbugli: So, if you’re in this situation, you have your product, you’re working on a new product, or you’re working on a product for a company, how would you go about validating a new feature, idea, or concept with enterprise clients? How could you make sure that the feature or the improvements that you’re putting in place will actually drive value for the customer?
Jason Knight: Well, a lot of it is about discovery, and that’s not something that all companies that serve the enterprise are particularly good at. And to be fair, a lot of companies that serve any type of company, not everyone is doing discovery half as much as Teresa Torres says that you should. And that’s just the thing that we have to own up to.
I think it’s especially bad in business when you’re maybe working with smaller markets, smaller, more niche functionality. Maybe the people that you want to talk to; there just aren’t that many of them. I think that that in itself does open up an opportunity because you can get closer to those people.
Like, one guy I was speaking to a little while back, he works with like five oil companies or something like that. That’s the entire Total Addressable Market. There’s very little chance for him to just go out into the street with a clipboard and say, “Hey, what do you think about my oil platform?” That’s not going to happen.
You can build very good relationships with these people, but you want to be careful that you’re not building too great relationships with these people so that you’re just building stuff specifically for them based on their very niche desires. But at the same time, you do get the chance to have discovery with these people, have discussions with these people, start to understand their world, develop empathy with those people, and start to understand what things are going to move the needle for them.
If it’s not that bad, and you’re still working in a fairly small market—not a mass market, social media, but you’re still working, say, with a lot of banks, a bunch of financial institutions—we’ve got plenty of people we can talk to, so you just have to go and talk to them. But, of course, then you get this user versus buyer dynamic, again, because you want to make sure that what you’re building is useful for the people that are going to be using it, but also hits the strategic goals that the people that are buying and signing the checks care about.
So, there’s a lot of discovery. You want to do discovery on a couple of different levels. Obviously, there are other sources that you can use. Like, if you’ve got a sales team, they’re talking to customers or prospects all the time. You can’t just do everything the sales team says in the order they say it because that makes it a very tricky conversation. But at the same time, you shouldn’t just discount sales feedback or customer success feedback, account manager feedback. These are all good sources of feedback.
You should absolutely try and bring those in and synthesize those in as much as possible, alongside things like industry reports. Of course, if you’re working for companies working with the enterprise, these enterprises are going to be in an industry of some sort. And there will be Gartner and other types of reports out there on these things where you can start to try and dig out macro-level trends, try and dig out industry experts.
Again, are these as good as doing a good old-fashioned discovery? Maybe, maybe not. But you still have to be conscious of the fact that these reports and data exist out there and really try to get ahead of the curve.
You see, the constant problem that people have with, say, sales-led feature requests and people being bullied around by big clients and stuff like that, for me, if you’ve done your positioning work and your value proposition work well enough, and if you’ve done enough discovery that you’ve actually managed to build things in advance of people asking for them, then anything that you actually get asked for becomes truly niche. And you can discount it on that basis rather than people legitimately coming to you with things that your product should do and it didn’t do it because no one asked for it yet, and you didn’t think about it.
So, I think that it’s important to get ahead of the curve. And a lot of that boils down to discovery. And then, of course, try to build as little as possible, in a very lean fashion, so you can get that in front of people. Now, again, if you’re working with enterprises, they probably don’t want you turning stuff on and off too much. With us, again, if you’ve got an API product, people don’t want the API response to change all the time. This is plumbed into their systems.
So, you need to be very careful with that. And that’s when you start offering rather than just random A/B tests, moving the button around, and all that sort of stuff, start to think about things like beta programs and guided demos and stuff like that.
Etienne Garbugli: In that case, you have all these different signals that are coming in, maybe some of the customers have your phone number so they’re calling you asking for things directly. You have sales on one side, you have your executives, you’re getting feedback, you’re seeing the analytics on the product, things are not exactly perfectly the way you want them to be. You’re also figuring out what the core is.
As a product leader, how do you make sense of all these signals to know what is the core and what you should be prioritizing when there are multiple stakeholders when there are both on your side and the customers’ side? How do you make sense of all this?
Jason Knight: Well, you just do what the CEO says. That’s the easiest. I mean, it’s hard. It’s more of an art than a science, I think, to some extent. If, for example, you’re in that 30%, 40%, 50% one client situation, a lot of times, you’re going to end up doing stuff for that client. Because, again, if that client walks, so do some of your colleagues. You have to be conscious of that reality.
If you’re in a position where you’ve got a healthier mix of revenue and you’re not in a position to be bullied so much, then a lot of it then comes down to, well, what is your position? What is your strategy? What is it that you actually say that you do? What is it you’re taking out to the market with your salespeople? What do you claim that you should be able to do? Are there things that people are asking for that fit within that?
Now, I’ve seen a similar concept of don’t go out to clients or customers or users and just ask them for feature requests because either that implies that you’re just going to do them in the order that they get asked for, and that’s not necessarily true, or you might not even do them at all. So, it’s more about asking for feedback and reassuring people that this is all being looked at, that you’ll go back to them with an answer. Some of the stuff you’ll do; some of it you won’t. And if you can’t do it, either, “Here are some workarounds,” or, “Sorry, you’re just going to have to use a different tool.”
Now, that’s not an easy conversation for all types of companies, especially if you’re a smaller company, if your revenue mix is off, or if you’ve got lots of competitors that do this stuff already. You can start to feel very defensive and you have to build these things. And you will get a lot of pressure from the higher-up people in the company because, again, they don’t lose all this money. You have to be very conscious of that.
I think that, as with anything, you are going to have to be flexible from time to time. Again, a big client wants something, an existential problem if they go, you need to work something out. If you have compliance or regulatory stuff that you have to handle that is just a legal requirement, then that’s going to have to get done from time to time. You don’t really want to be in a situation where you’re prioritizing stuff just because a client asked for it or a prospect asked for it. That’s never a great position to be in.
But if you are pushed into that situation, first of all, try and track or define metrics that you can track to see if that was a successful thing. Did we win that deal? Or did it go in the same bucket as all the other deals that we didn’t win from all the other things we’ve got asked for?
And try to abstract or genericize what people are asking for as well. So, if they come to you and say, “We want a button to do X,” well, first of all, is that a thing that supports the goals that we’ve identified before? Does that support our strategy? Does that support any of the functionality that we claim that we should be doing? Okay, fine. Well, maybe we consider that.
But can we make that a button that doesn’t just work for one client? Can we make that a button that works for larger clients? Is this actually a functionality that we should have? Is this really just a different type of discovery that people are asking for stuff? Just because you didn’t ask them first doesn’t mean that it’s not something that you shouldn’t then investigate and say, “Okay, fine. Well, people want this button. Let’s go and find out what’s the job to be done, or that classic discovery stuff.”
But once you’ve identified what they’re trying to solve, is this actually something that we want to solve? Let’s go and do some more discovery and find out if that is something that we want to solve.
I think a lot of it all boils down to the fact that many companies don’t actually have solid product strategies. They’re just doing what people ask them to do. And there’s nothing wrong with that as an approach as such, but plenty of companies just do things that people ask them to do and are moderately successful.
But I do think that if you want to really make a big difference and deliver something that they can’t get anywhere else, then you have to get ahead of that curve, get used to turning down feature requests and random segues of, “Hey, let’s do a blockchain,” or whatever it is that comes up in day-to-day business, or because the CFO or the CEO saw an article and thinks that is a thing that we should look at now.
You have to get ahead of that curve and you have to concentrate on what’s actually important, what your differentiating value is, what your IP is, to some extent, and what people cannot get from other people that they can get from you. Otherwise, you’re just racing to the bottom.
So, try to make sure that you do have that strategy, a strong position, and that’s what you’re actually selling rather than going out there just selling whatever the person in front of you asks for. Because, again, you just end up chasing your tail in that situation. And half the time, what they ask for doesn’t even win the deal anyway.
Etienne Garbugli: Well, if we talk about that, then how would you go about clarifying that strategy, that plan, or that vision, or what you’re about that allows you to make all these decisions afterwards?
Jason Knight: Well, I mean, a lot of this presupposes that the company has a strategy. You’ve got to start there. If you can go up to the leadership of your company and say, “What’s our strategy?” and they can’t tell you, then there’s some work to do there. And hopefully, if you’re a product company and that’s all you sell, you can be very instrumental in helping to set that strategy.
But if there is a company strategy, then do you have a product strategy? Did you bother to take the time and make one? It sounds stupid but not everyone does. Or, worse still, you find companies where they have multiple product strategies all going in different directions for different bits of the same product. That’s a tricky one because you get a lot of politics even within a startup.
It’s a complete lie that startups are completely egalitarian, politics-free zones. There’s plenty of politics in startups because these people are just people that come from other companies originally. There’s no special thing about startups that people don’t get protective or defensive about their ideas or start playing games.
I think, ultimately, it requires strong leadership. If you don’t have strong leadership, then you’re in trouble because you can’t necessarily affect that yourself. But if you do have strong leadership, then working with those people to try to get to the nub of what it is that you actually offer, and not just that you’re just doing whatever comes in.
As an example, my company merged with another company mid of last year. It would have been the easiest thing in the world to just do whatever came up in the order that it came up. But we spent a lot of good time with both sides of the house as we came together as a company, to work out what the strategy was, what the position was, what the vision was, what we were going to do as a combined entity, the problems that we’re going to solve, what we’re not going to solve, and what things we’re going to need to prioritize to get there.
Now, of course, that’s always going to get put under stress when the next big client comes in waving 50 grand. That’s always going to happen. Again, sometimes you’re going to have to think about it and say, “Well, actually, we really need that 50 grand.” And you have to try and then do something to get that.
But if you really have a strong position and you’re sitting there saying, “This is what we’re selling, these use cases are the ones that we claim to be able to serve, and these are the people we claim to better serve,” then anything that isn’t inside that becomes legitimately niche. And it’s fair enough if the leadership team comes to you and says that they want you to go in a certain direction because of X.
But at least you’ve done the work in advance and you call out and say, “Okay, fine. Well, if we have to do that, we also have to appreciate that that’s off the plan. If you’re making me go off plan, that’s cool, but we have to understand that the plan isn’t the plan anymore and you’re not able to just add stuff on.” Things become a no or not an end. So, people have to realize.
And in many cases, if they sit there and say, “Well, but we still need the plan. Okay, we have to choose.” Maybe not quite like that, but much more delicately than that. But people do have to choose; you can’t just do everything at the same time.
Etienne Garbugli: So, you’re using that strategy or these guidelines that you defined as a lens from which to analyze everything that’s coming through?
Jason Knight: Yeah.
Etienne Garbugli: In that case, I assume that that probably pulls you in a more strategic decision or pulls you in certain directions. How do you make sure that some of these other things that we talked about, like the end-user satisfaction, or maybe technical debt, things that tend to be pushed on the side, also get addressed? Do you have different buckets that you’re working with? How do you make sure that everything at least gets touched when they need to be?
Jason Knight: I think that operating some level of a portfolio is not a bad strategy, especially if you’re in a more complicated company. And, of course, it doesn’t really get much more complicated than sticking two companies together as we’ve been doing. So, there is stuff that we have to take care of that isn’t immediately user-beneficial; platforms coming together and stuff like that. And that’s fine.
You have to allocate some level of time for that because it is important. I’m definitely not of the opinion that technical debt is this nice-to-have fixie thing that you do when you’ve got some spare time or when all of the user work is down. Because, A, the user work is never done, and, B, be the technical debt eventually will affect the users. We all know this.
You can’t just have a system that’s just getting worse and worse and worse, and just keep building on top of it. Eventually, it’ll give way.
I think one of the big things for me is, well, if we’re, as product people, going to our senior stakeholders, to the other people in the business and saying, “Hey, I want to shut everything down for six months to do a re-platforming effort,” that’s never going to fly. No one wants that, especially when the end result looks basically the same as the beginning, it’s just on faster service. We know that there are benefits to that. We know that it’s good for the business and good for our users, but it doesn’t look any different and people are going to struggle to bond with that if they’re not technical people and they don’t understand what we’re doing.
So, a lot of the work that I think good product teams do is try to translate that technical debt work not into, “We need to move from this type of bucket to this type of bucket,” but actually, “This is the before and after state, and what it means to our users.” What does it mean to our users? Well, if we don’t do this and we get one more client, we’re dead. That’s maybe an extreme example, but that’s something that resonates with everyone.
We did a demo of my company the other day where the engineering team showed a before and after of some big migration effort that’s gone in the background. It’s been a portion of our work, it’s been going alongside other initiatives. The ultimate upshot of it was a big bunch of performance improvements. And you could see in real-time, doing some load testing, how many extra users we can support on less hardware.
That’s something that resonates with the business as a whole because there’s a financial impact there. We’re using fewer servers and we’re able to serve more customers. So, the next time we get that big account from whoever or we’re selling into whoever the next big point is, we’re able to support them without blinking. Rather than having to worry every time we get an account that there’s a whole new amount of work or shoveling to do just to get those onto the start point.
So, I think technical debt is crucially important. Coming from a development background myself, it’s not something that I’m ever going to ignore. And it’s the same when it comes to bugs, CS requests, and stuff like that. There are going to be things that come in. Not all software is perfect. You’re going to be in a situation, from time to time, where there’s a legitimate blocking bug that comes in and you’ve got to fix it.
If it’s a blocking bug for functionality that is supposed to work in your platform and there’s no way around it, you probably have to fix it. You don’t have to drop everything and fix it instantly, but you definitely need to fix it pretty soon. If it’s something we can work around, well, try and work with the CS team to get a workaround to keep people happy. If it’s something that you legitimately can say isn’t a thing that we ever said worked, it’s actually a feature request, then that just goes into the same funnel as all your feature requests.
So, I don’t treat all bug reports as equal. I think you need to categorize them and have a triage process and just get them through. You do, obviously, need to keep your customers happy because if they’re not happy, they’re not going to renew. People will live with a lot. As it turns out, people don’t expect perfect software, especially in the enterprise where they’re used to not having perfect software. But at the same time, it’s like Death By A Thousand Cuts.
If you keep having bugs, inconsistencies, performance problems, and stuff like that, then eventually, they’re going to go. So, you do want to keep on top of the worst stuff and put it through the prioritization lens, try and have a good triage process. Again, if we have that portfolio approach across the top and say, “Well, fine, not exactly. But ideally, we want to spend roughly 10% on this sort of stuff, 20% on this sort of stuff, 70% on the rest of the stuff.” Just try to make as much progress as you can in different areas and keep as many people happy as possible.
Etienne Garbugli: If I’m reading between the lines, I’m understanding that things technical debt, for example, or bugs, you’re looking at it like I need to have some business case for these oftentimes, either to justify to your internal stakeholders, or just to make sure that there’s a rationale if people are asking why I’m doing this, versus I’m doing that?
Jason Knight: Yeah. I think it’s important for the product team to have a good solid hold on things like bugs, things like tech debt because they are going to be service-impacting eventually. And if we care about our users, we care about our services working.
At the same time, I don’t want to sit there having arguments about whether something is more or less important than something else if that thing actually isn’t important.
For example, there’s a rounding error on one part of a scorecard somewhere but, actually, the number is fine. It’s just 0.01 and the margin of error is more than that anyway. Yeah, sure. It’s frustrating, but it’s easily explainable and we’ll get to it. Whereas clicking the download button to get a report and the report doesn’t come; that’s a big problem and there’s no way for them to fix that. So, that becomes a more important thing.
So, I think it’s important to, again, have a good triage process when you’re working with enterprise customers. What we’ve got to realize is that enterprise customers, in many cases, are used to more of a service engagement with other types of enterprise companies that sell them services on top of the platforms if they even sell them platforms. So, there is an expectation to some degree, especially when they’re spending 10s, or hundreds of 1000s of pounds, or dollars, or whatever it is that they’re spending. There is an expectation for quality there.
That doesn’t make it easy to do things like MVPs, and quick tests and stuff like that, but at the same time, the stakes are higher. So, you have to be very conscious of what you can and can’t do with these people. At the same time, this whole concept of just saying no to every single request doesn’t 100% fly. You can’t just say yes to everything, but you can’t say no to everything when there are hundreds of 1000s of pounds on the table for certain requests.
So, you want to be as good product management people as possible, and you want to put everything through as much of a good decision process as possible. So, you’re not just twitching and jumping around doing whatever comes up next because someone shouted. That’s not B2B product management. At the same time, it’s not just as simple as saying, “Oh, well, if this person isn’t happy and they leave, then pay whatever.” If this person leaves, that’s 12 people who have to get fired. It’s not quite the same relationship.
Etienne Garbugli: We’ve talked about a lot of the challenges of being a product manager in an enterprise with enterprise products, or working in an enterprise with products. We’ve talked about prioritization, working with different stakeholders, also managing different stakeholders and their expectations. What do you feel are the advantages of going enterprise-first when you’re a startup or starting with the enterprise?
Jason Knight: I guess one of the biggest advantages is there’s a lot of money there to be had. Again, I think you talked about this in your book in your first edition. If you get it right, then these are big deals. They can sustain a lot through these deals. The annual contract value can be high, the retention and the switching costs are sometimes quite high as well. So, if you get embedded with people, you can become true partners to them, and really help them A, enable their business, and B, sustain your business.
And these are good things to do. Also, for me, a big attraction about selling into enterprises and selling into businesses, in general, is, as we touched on earlier, a lot of times these people are used to using really terrible software. Now, I used to work in an enterprise and I know some of the horrible software we have to use because some person in some part of the company knew someone from that company that provided the software. That was their favorite software and it was a little bit cheaper than the other software or whatever else.
We were just sitting there, day after day,10s of 1000s of people slogging through horrible applications, things crashing all the time, functionality missing, doesn’t connect to other stuff, then you’re just sitting there in the evening working on some side project or just doing your social media or whatever, just seeing how good things could be.
I think there’s a lot of joy to be brought to people’s lives, if you can build good enterprise products for people that are working in these companies that make their lives easier, save time. Save money for their companies, sure, but just make their lives easier. I mean, no one should be sitting there in this day and age struggling and slogging through these horrible applications, just doing horrible repetitive work and feeling valueless because they don’t get time to do any good thinking because all of the work is spent jockeying data between different applications or whatever.
I think there’s a lot of meaningful change that you can make by building good applications for big businesses because the amplification is such because of the scale of the people that you’re selling to, you’re making a decent effect on the large number of hours that people spend at work every day.
Etienne Garbugli: That’s a great point. Maybe as a last question, how do you see the B2B space evolving moving forward? What trends are you tracking?
You’ve been around a long time; you speak to a lot of product leaders. I don’t mean that as a negative. You speak to a lot of product leaders, you’re at the forefront of a lot of these things. How do you see things moving forward?
Jason Knight: Well, I think there are a couple of trends I’ve seen and think are going to bubble up a little bit more in B2B this year. I think discovery is becoming more and more of a popular concept. I mean, it’s not a new thing, of course. People have been doing that in “proper” product companies for a while now. But I think it’s something that’s been not so quick to catch on, especially selling into the enterprise because of these sort of high-value customers and talking to people with specific domain skills.
I’ve definitely been in conversations in the past where I’ve been told, “Hey, your team aren’t 20-year experts in this industry so you wouldn’t be able to talk to these people.” Well, that’s actually not true. I think that B2B discovery is going to become more of a thing.
I’d also like to think that people are getting used to the idea of doing discovery with sales. They’re actually involving themselves and getting close to the sales team. That’s certainly something I’m trying to push for as well in some of the commentary that I do and some of the work I do. We can’t treat sales teams, marketing teams, and customer success teams as the enemy, or worse still, like a whole different area of the world and we’re not in that business.
We’re all in the same business. We’ve all got the same basic goal of a successful company. We just have different ideas about how to get there. One of the things that I’m hoping will happen over the next year or so is people start to, from the product side, move towards those people, as well as expecting those people to move towards us.
I think it’s so common for us to sit down and say, “Salespeople suck because they just care about sales.” But that’s their job. They’re being paid to sell stuff. They’re not being paid to develop a product. If you can give them a product that they can sell, I’m sure they’ll sell it, and they’ll happily sell it.
So, maybe read a book about sales every now and then rather than just reading all your product books. Just try and get closer to them and empathize with them, as well as them empathizing with you.
I also think that the product Ops trend will be ongoing. And as companies scale and some of the more established companies and startups that are selling to B2B get bigger and have to scale out and get more complicated, I do think that product Ops will be a burgeoning trend as companies start to scale out. There are a lot of companies now going unicorn or getting bigger and scaling really strongly. So, I think that product Ops will be a thing and I don’t think that’s going to go anywhere anytime soon.
Etienne Garbugli: Awesome. Thanks for taking the time, Jason. Where can people go to learn more about your work, your podcast?
Jason Knight: Well, if they want to learn about the podcast, the easiest place to go would be oneknightinproduct.com. They can also find me on Twitter @onejasonknight. Also LinkedIn, just Jason-Knight.
Yeah, I’m happy to chat with people. I’ve been doing a lot of mentoring recently. It’s been really eye opening. I think it’s really good to just hear people’s stories from companies that I haven’t worked in and start to understand that the things that I’m hearing and seeing, and in some cases assuming are actually true. And you hear those again and again.
So, I always love speaking to people, always love connecting with people. We’ll get through this B2B product management stuff together.
Etienne Garbugli: And you got to get the memes. The memes are amazing. Thank you.
Jason Knight: I think that’s the thing; if you can’t be insightful, at least put a funny picture on the bottom and then people will like it anyway.
Etienne Garbugli: Well, there’s a little skill there. Thank you very much.
More on B2B Product Management
- [ Interview ] Sachin Rekhi on How to Get Actionable User Feedback for Your Product
- [ Interview ] B2B Product Positioning Expert Nkiruka Nwasokwa on Creating Value Propositions That Sell
- How Cobrainer Used Consulting to Bootstrap and Validate an Enterprise Product
Download the First 4 Chapters Free
Learn the major differences between B2B and B2C customer development, how to think about business ideas, and how to assess a venture’s risk in this 70-page sampler.
Enjoyed this Episode?
Subscribe to The Lean B2B Podcast for more: