Mind the indirect Switching Costs - Product Thoughts #115
Tim Herbig
Product Management Coach & Consultant | I help Product Teams connect the Dots of Strategy, OKRs, and Discovery through better practices.
Most of you are probably familiar with the concept of Jobs to be Done. It's a way of looking at user's need not in terms of a specific solution, but the underlying desires they try to fulfill.
But one aspect of the whole JTBD framework always stands out to me: The concept of switching costs. The folks over at Strategyzer summarized it pretty well in this drawing:
But when product people talk to users about existing solutions they use, they tend to only focus on direct competitors. For example, at iridion, one of our direct competitors is Effective Experiments. Now, if I would start the user interview by only asking people if they use this tool and the answer is "no," I would probably abort the conversation because the user doesn't seem to have the problem we (iridion + Effective Experiments) are solving for her.
But by limiting your perspective only to direct competitors, you're missing out on the truth. So, don't ask people if they have recently used a direct competitor, but when the last time was they, e.g., ran an A/B test. By using the Post-it your Customer-Journey method, I guide the user to walk me through his or her last experience completing this task. By continuously asking “What did you do after this step, and why?” I will then get to the bottom of their used tools.
In the beginning, people might say "Oh, no I don't use a tool to structure my A/B testing efforts" but will ultimately tell me how they make use of shared Google Sheets and file servers to set up an ideation process and document the experiment results.
This way, you can uncover what I like to call "indirect competitors." Your users might not be using a direct competitor, but are already hiring one or many other tools to get their job done. The reason why it's so important to uncover the indirect competitors is that these often-times carry much higher switching costs. If e.g., your target audience is using a software suite like Office365, GSuite or a JIRA/Confluence combination, it will be much more difficult to convince them to add your tool to the mix. Indirect competitors not only increase the switching costs but also force you to deal with different customers. Especially in b2b environments, your customer is no longer just your user, but users from other departments using the existing tools as well and overarching roles like procurement or IT security.
So, remain open-minded when thinking about who you're competing with. And, depending on the outcome of your research, you might want to reconsider adapting your strategy to avoid a particular set of (indirect) competitors. A great way to visualize this often-times fundamental shift is the Product Field.
Have a great week and take care,
Tim
PS.: If you bought a copy of my book on Lateral Leadership, it would mean the world to me if you could take 30 seconds to leave an honest review on Amazon. ??
What I read this Week
What if there were a few simple rules you could follow to increase the agility of your organization? I’ve been using these rules in my coaching recently, and have been seeing exciting results. Now, I’m honestly not sure that these rules are comprehensive, complete, sufficient, etc. But they’ve been pretty useful recently, so, having apologized in advance, here are two simple rules to keep in mind as you seek to increase the agility and effectiveness of your organization.
Marty Cagan recently called her an “exceptional discovery coach”, but we’ve known that Petra Wille is special for a long time. One of the co-organisers of the MtP Engage conference in Hamburg (and a featured speaker at the Leadership Forum this year), she gave a talk a while back on Egoless Product Development. We wanted to dig in deeper on what that means, the deck of cards she’s produced to help get you unstuck, and more.
The Netflix Decision Making Model Is Why They're So Successful
How does the company balance a high debt load and lofty subscriber growth targets with the need to offer creative programming to its growing audience? In part, it has to do with the company’s decision-making DNA. Other organizations would be wise to take notice.
Prioritize Opportunities, Not Solutions
I cringe every time I see product teams use a spreadsheet to rank the ideas in their backlog based on some made-up math formula usually consisting of things like business value, user value, and technical difficulty. While this exercise is pervasive, it misses the point entirely. Our job is not to prioritize solutions. A product team’s job is to create value for the customer in a way that creates value for the business. This is rarely done by fixating on a ranked idealist.
A common misunderstanding — that is unfortunately perpetuated by some JTBD enthusiasts — is that a Job to be Done has some functional quality to it. This is incorrect. There’s nothing functional about my desire for progress. Rather, it is the product that functions. I have progress I want to make, and I hire a product to do the function (i.e. work) for me. That is the whole reason why it’s called Jobs to be Done.
A common misunderstanding — that is unfortunately perpetuated by some JTBD enthusiasts — is that a Job to be Done has some functional quality to it. This is incorrect. There’s nothing functional about my desire for progress. Rather, it is the product that functions. I have progress I want to make, and I hire a product to do the function (i.e. work) for me. That is the whole reason why it’s called Jobs to be Done.
Coaching Tools – The One on One
I’d be surprised if you haven’t at least heard about the coaching technique known as the “one on one” (aka “1:1”). And you’ve probably experienced some version yourself. But judging from my discussions with literally thousands of product managers and product leaders, you may have never experienced this technique done well. Yet this is the foundation of coaching. Several others have written about the benefits of this technique, but usually, the context is an engineering manager meeting with an engineer. In this article, I’d like to share how I do these sessions when I am coaching product managers.
Product Thoughts is a weekly newsletter/digest I send out to over a thousand leaders in product, ux and business every week. To learn more about previous editions and sign up for it, go to herbigt.com/newsletter.