Product Mindset: Getting Started

This is the second in a series of articles diving into the product operating model. In this installment, we provide some practical suggestions on how to manage change and how to get started with product thinking in your organization. Subscribe here to get notified when the next article is live.

It sounds simple but….

Now that you’ve solidified your understanding of product mindset and why it matters, you know that applying product thinking can increase the likelihood that customers will actually use the software you build. If product thinking is foreign to your organization, but you like the idea of building software that customers love, you might be ready to put product concepts and practices into use. In this article, we will discuss some simple, low-risk ideas for getting started. First, though, let’s start by talking through some common objections you might encounter.

For many organizations getting started may not be as simple as it sounds. In fact, maybe you’ve previously suggested product thinking to your organization only to experience pushback and resistance.  

As with any change to how people work and think, you should expect some level of friction. Introducing product thinking to an organization that has historically operated with a project mindset is no exception. There is comfort in the predictability of project thinking so any perceived disruption to that comfort is bound to cause some anxiety. While every organization responds to change differently, here are a couple common objections you should anticipate when initially introducing product thinking.

Objection #1: Talking to Customers

The first, all-too-common hurdle for teams who wish to employ product thinking is getting the organization comfortable with talking to customers. Many aspiring product teams simply are not allowed to talk to customers. This is particularly common within companies that field a sales team who ‘owns’ the customer.  

If you want to build products that customers love, you are going to need more than the anecdotal evidence your sales team can provide. There is no substitute for what can be learned through direct interaction with a customer.  

Objection #2: Less Time to Deliver Software

A second commonly encountered objection to product thinking is the misconception that teams will spend an inordinate amount of time talking to customers and researching problems – and a great deal less time actually delivering software. Organizations that have operated with a project mindset are conditioned to maximize efficiency and continually encourage teams to deliver as much software as quickly as possible. Unfortunately, much of that software fails to bring value to customers.  

Product thinking challenges us to get the right software into our customers’ hands as quickly as possible. Talking to customers, understanding their needs, and delivering value incrementally actually helps us reduce software waste and makes our teams more effective. 

Navigating roadblocks and skeptics

Your path to adopting product thinking will likely be  littered with roadblocks, skeptics, and impatient stakeholders. You’ll encounter objections like those mentioned above and many more. But if you can go into the process aware of this, you’ll be better positioned to champion this change for the long-haul. Here is some practical advice to help you navigate these obstacles and introduce a better way of building products your customers will love:

Understand who has objections and why. Sales professionals, for example, may naturally be concerned that interacting with customers could put their relationships at risk and lead to attrition and lost revenue. Attempt to build trusted relationships with your skeptics by offering to walk alongside them in their roles, patiently observing, asking probing questions, and opportunistically gathering insights (ex: can we ask the customer this question). As these relationships grow, fears will subside, understanding will increase, and the customer will win.  

Be transparent. Employing product thinking can be a new learning experience for not only you but many in your organization. Be intentional about setting expectations, sharing what you are learning, and don’t forget to speak to the ‘why.’ What you are learning from customer interviews, how you are responsibly testing ideas, and the results of learning experiments are all great examples of where you can be transparent and educate the organization. Consider including these elements in your stakeholder demos to illustrate how your team is becoming more effective and finding a better balance between quality (value) and quantity (lines of code).  

Leverage your organization. Many organizations have user research capabilities and/or marketing teams that are already gathering customer insights. Stakeholders tend to trust these groups to interact with customers – something product teams often struggle to overcome. Instead of trying to replicate elements of what these groups do (which is certain to look like duplication and waste to your stakeholders), choose to collaborate with your marketing and CX/UX teams to leverage their expertise and accelerate your team’s understanding of the customer. Seek opportunities to partner on research projects, customer surveys, product promotions, etc. In doing so, you may find openings to opportunistically influence the insights they harvest. Building products is a team sport and working in partnership with these groups will produce wins for all.

Avoid big arm movements. Introducing product thinking to an organization that has only known project thinking is likely to take time – more than you probably wish and expect. Avoid the temptation to push for mass changes (ex: we want all of our teams to have access to all of our customers starting next week). Start small (ex: one idea, one initiative, one team) and work incrementally. Model and promote learning and experimentation. Evidence can be incredibly empowering and extremely influential in directing stakeholders away from opinions – so be transparent at every turn. Build a bank account of trust and leverage it wisely to scale your change.

But where do I start?

So now that you are prepared to deal with some of the obstacles that might stand in your way, let’s talk about some simple ways you can begin to introduce product thinking into your organization. As we’ve shared throughout this article, we like starting small, framing what you do as experiments, being transparent with what you’re learning, and educating the organization as you go. Not only do we believe this is more judicious and lowers the overall risk to an organization, it also typically doesn’t require ‘permission’ from layers of leadership.

Here are some suggestions for incremental changes you can introduce within your span of control to put your team(s) on the path to product thinking:

Change how you build software. Sure, product thinking is about building the right thing. But if  your team is unable to deliver high quality software at a rapid pace, your best ideas may never make it across the finish line and into your customers’ hands. Developing the muscle to deliver quality software at least every two weeks (sorry SAFe fans) is fundamental to operating with a product mindset. So if your team isn’t delivering frequently, or what they are delivering lacks quality, you need to first ‘get your house in order.’ Build it right – then focus on building the right thing.  

Change how you learn. Talking to your customers is a great way to improve your understanding of their needs and how software can help. It may take time and patience, however, to create the necessary relationships and trust to get your organization comfortable with talking to customers. If this is the case, you can still begin to learn valuable insights about your customers through the use of instrumentation and monitoring. Building these capabilities into your products will allow you to learn how customers are using your software and the behaviors your software is encouraging. These insights will not only validate you have built the right thing – but will also inform your decisions on what to build next.  

Change how you organize your ideas. Most teams operate from a feature-filled roadmap and/or what might seem like an endless backlog of ideas. If opinion and anecdote have largely influenced what your team is working on, it is time to consider how your team can become more evidence-guided in what it builds. Proper evidence can help us validate our ideas will be successful and avoid the trap of building expensive software that never gets used. Evidence can empower a team and diplomatically direct stakeholders away from opinion. Curious to learn more? Check out this short (16min) talk on how to leverage evidence to organize your ideas.  

Change the targets at which you aim. While many teams operate with goals, we find there are often too many and they tend to speak about what to build, who will build it, how to build it, and when to build it. If this describes your team’s goals, you should consider changing your aim. Start by paring the number of goals down – typically 1-2 goals will sufficiently cover what a team aspires to accomplish. Next, we suggest refactoring goals to be outcome-focused. Rather than articulating what to build, design your goals to reflect the value you intend to deliver to your customers. Specifically, what value will our software provide our customers that compels them to give us something (ex: money, subscriptions, data) in return. Finally, identify how your team will measure progress against their goals. The measures should tell you if your software is bringing value to our customers.

Go forth and conquer!

Getting started with product thinking doesn’t have to be a revolutionary shift. Teams can become more customer-focused in what they build by making a few small adjustments. Some things to keep in mind as you begin your journey: 

• Every organization starts from a different place, has different challenges, and often takes different routes. While tempting, resist the urge to compare your organization to another. Instead, compare your organization to its former self of last week, last month, or last year. It’s about progress, continuous improvement, and steps forward.
• Remember that perfection is the enemy of good. The steps you take, the experiments you run, the changes you try may not all produce wins.  Vince Lombardi said, “perfection is not attainable.  But if we chase perfection, we’ll catch excellence.” Doesn’t that sound better than what you are doing today?

What’s Next

So far, this series has armed you with a better understanding of product mindset, prepared you for some common objections you are likely to face, and provided you with some practical suggestions for how to get started. We hope you are starting to feel more confident in your knowledge and know-how. Experience tells us, though, we need to dive a bit deeper to truly help you deliver meaningful change. In our next article, we will provide tangible examples of what our advice looks like in practice. Additionally, we’ll share ideas on how to measure the product mindset growth of your organization as you take steps towards building for (more) impact.