For most product people, Marty Cagan needs no introduction. Often referred to as the “Godfather” of modern product or the most influential person in the product space, Cagan’s bona fides precede him.

I’ve recently begun the next step, which is to focus on those people who are trying to help product teams, product leaders, and product companies. I refer to that as “coaching the coaches,” and it’s an acknowledgment that far more teams and companies need help than there are people with the knowledge and experience to provide that help. So, we’re trying to do our part to address that problem. We are starting by helping to develop a network of coaches in Europe but hope to take that to the rest of the world.

What I hope people take away from both books is that the best product companies in the world produce products in ways that are very different from most companies and that it’s not an accident that they are also the most valuable companies in the world. And most importantly, there’s no reason you can’t change to work like the best companies.

There is no question that the bar is higher today than it has ever been, and customers have more choices than ever before. But despite the crowded playing field, the key is to truly take care of your customers and not worry so much about competitors. It’s remarkable how many companies I meet that give lip service to caring about their customers but, unfortunately, have little idea of what it means to truly work to continuously innovate on behalf of your customers.

Every good product team I know uses both quantitative and qualitative techniques. They are both critical because they answer different questions. The quantitative techniques tell us what’s actually happening (good or bad), but they can’t tell us why. The qualitative techniques help us learn what’s wrong with our products and provide great inspiration for how to fix them.

The higher-order point is that if you are doing user-facing products, you need a steady cadence of getting in front of your customers. Normally, that means the product manager, product designer, and at least one of the engineers spend at least an hour each with three different users or customers every week. We combine this with quantitative techniques (such as running A/B tests to see which solution approach performs best).

If resources are limited (especially time and money), then that makes this work especially critical, as it’s all about learning quickly. It’s much faster than older approaches where someone would just take a guess and then spend months to build, QA test, and deploy, only to find out customers didn’t want it.

But it is important that product teams pace themselves. I often find teams spending way too much time validating that customers actually have the problem (even when the evidence is clear) and not nearly enough time figuring out if customers will actually buy their approach to solving the problem.

When you cut to the chase, what’s really hard about product is coming up with a solution that is so much better than the alternatives that the customer is willing to switch.

There’s no question this is a real problem in some companies. I’ve seen product managers working without a trained product designer or user researcher, and also not including their engineers (but that’s a different issue), and just going nowhere fast.

I advocate a compromise that is used at many strong product companies. These companies have a relatively small number of professional user researchers to coach and enable the product teams to do good product discovery work every week. Realize that this model depends on having professional product designers on these teams, and also realize that most professional product designers have had some level of training in user research. So the combination is powerful.

It’s worth pointing out the problem on the other extreme.

Why? Because they weren’t there learning firsthand. I tell user researchers that their work is too important to be ignored, and they need to enable the product teams to learn directly if they want to have a real impact.

Yes, we love intercept testing and have done it for many years, but today the tooling makes this easier than ever. The concept is simple. If we are building an app to help someone book a table at a restaurant, you could go to pretty much any adult and ask them if they’re ever booked a table at a restaurant before, and if so, could they please pretend to do that now so we can see how well our app solves that problem. However, if we can get people that are actually in the process of booking a table, the learnings will be much more valuable. In the first, the focus is usually on usability. In the second, you quickly get to the tougher issue of value— would they really use this to book a table?

One use of user research firms is to recruit users, and of course, with intercept testing, that process is essentially automated. But the actual running of the test and interpreting the learnings is where the user research skills are still critical.

In truth, product discovery is only relevant if the product team is empowered to actually come up with the solution. Sadly, most companies are not working like the best companies, so they don’t empower their teams. Instead, many stakeholders, executives, or even customers (which is why we hate focus groups) tell us what features they want us to build.

In which case, all the product team is asked to do is design and implement that feature, build and QA test that feature, then deploy that feature. We call these feature teams because it’s all about delivering features and projects on a roadmap.

Product discovery is necessary when we are instead given a problem to solve, and now the product team has to figure out a solution that will actually solve that problem. And that requires considering the various risks—value, usability, feasibility, and viability—and testing out different approaches until we discover one worth building.

The key is shared learning. Unless the actual product team—the PM, the product designer, and the engineers—learns the issues firsthand, they will not act on those learnings. So the key for user research is to enable that shared learning. Not to do the research for the team, and not let the team go off and struggle to do the research themselves. But rather to work with the product team to coach and enable them to do good research every week.

There are so many great places to start—I started as an engineer and have benefited from that to this day. Product design is a fantastic role and is in very high demand. Product management can be a stressful role, but it’s where many entrepreneurs learn the critical skills that eventually lead to running a startup. User research is a great place to develop true customer-centricity. Data analytics and data science are some of the fastest-growing areas.

I love building things, and today, almost everything is powered by technology. And the enabling technology changes literally every day. So every day, new things become possible. I think any other career would have been boring compared to that.