We love reading stories about incredible pivots where a company was about to plunge into death and then, by looking at its customer base closely, found the light at the end of the tunnel and turned the business around. It’s easy to think that those magical moments are very unique to early-stage startups. However, for more mature products, magical moments are less dramatic and more the consequence of teams compounding small but frequent nuggets of insights that ultimately help them connect the dots and innovate.

The companies that we admire today are great at building strong processes for understanding customers on an ongoing basis, as opposed to one-off research activities while hoping some magical insight will drive the entire product strategy. Those processes and the culture behind them are what leads to constant innovation.

This is what Peter Senge, in his book The Fifth Discipline, called TheLearning Organization:

“…organizations where people continually expand their capacity to create the results they truly desire, where new and expansive patterns of thinking are nurtured, where collective aspiration is set free, and where people are continually learning to see the whole together.”

A learning organization is less concerned about what it learns and more concerned about making sure everybody can acquire and transfer knowledge as much as possible and as easily as possible. Such organizations trust the outcome because they have hired curious people and given them the access to what they need to fulfill that curiosity and make an impact.

The Fifth Discipline was originally published in 1990. Fast-forward 28 years, and despite so much progress, we’re still struggling to build learning organizations.

Out of all business models, SaaS is probably the most interesting to analyze when it comes to building learning organizations. Software companies depend on learning and feedback loops to improve their products and services on an ongoing basis. However, since the popularization of the Lean Startup, the focus of the conversation has been mostly about learning fast but not necessarily learning better.

Learning better

Learning better means constantly adjusting the tools we use and the processes we build. But most importantly, it means challenging the way we think about them. Learning better is also about reducing friction. For example, friction can be the number of days a PM needs to wait for permission before she can talk to a customer.

If accessing customers is too cumbersome, it’s easier to give up the learning opportunity before even trying. It’s the accumulation of friction in multiple processes that stops an organization from learning.

If you’ve been working in tech for a while, you probably have been involved in some variation of a customer research exercise. At some point your team decided they needed to define personas, jobs to be done or some sort of user journey. Unfortunately, in my experience, that normally happens when the team realizes they’ve been far too long-removed from customers. These projects tend to pop up more as one-off initiatives rather than work-in-progress activities, and there’s a reason for it.

People don’t trust the outcome of the research.

Why? When we focus on the outcome — let’s say having a persona poster on the wall or a document with an updated version of the JTBD — when we focus on those deliverables, it’s very easy to overlook or compromise the research process itself. After all, the goal is to get it done. The goal is to learn fast.


In this context, for example, we may…

  • Only interview customers that we were allowed to talk to
  • Only use the limited data we have access to
  • Overlook cross-team collaboration because it’s easier and faster to get things done when fewer people are involved
  • Rationalize poor data quality with the idea that something is better than nothing

This is why we end up with the pictures on the wall but not much change afterward. We don’t trust the research results. And because we don’t trust them, we file them away until somebody comes back with the same idea again.

But what if we didn’t care about learning fast but learning better? What if we focused on the process and not the outcome?

When you focus on the process, you find problems like these:

  • Event tracking was not set up properly, so we can’t answer question X.
  • We don’t have engineering resources to put proper tracking in place until next quarter.
  • If we want to interview X type of customers, we need to get permission from department ABC one month in advance.
  • Marketing is running a similar research, and they think we should use that data instead.
  • We built an internal tool to gather XYZ data, but only the engineering team can export it.
  • We have a bunch of customer feedback we want to look at, but it’s stored in five different tools.
  • The business wants us to do more customer research, but it only hired one researcher to work with five product teams.
  • We want to work in more autonomous ways, but the boss wants to centralize all decision-making.

Each of those problems add friction to the team’s ability to generate insights. I would argue that, if we want to learn faster, we first need to learn better.

“Intelligence is always about systems” Peter Senge

Instead of asking, “What can we learn from our customers?” we should instead ask, “What would stop us from learning?” And then, start there.