Leader Spotlight: Enabling a vision-led product mindset, with David Krell

---

David Krell is VP of Product at Going. He began his career as a UX designer before cofounding and leading product at LOOKCAST, a commerce-minded content platform, which was acquired in 2017. David then spent 4+ years at Cars.com as a principal product manager before joining Scott’s Cheap Flights (which has since been rebranded to Going) in 2022.

In our conversation, David talks about the fallacy that PMs have to be in a position of authority to do vision-led work, indicating that’s not true in reality. He describes his practice of creating “ownership tables” to efficiently call out which teams own which features or initiatives. David also discusses how giving teams the structure of a co-created product outcome, as well as the opportunities underneath it, is the strongest way to create alignment between business performance and customer needs.

---

Having the authority to push toward a vision

In your opinion, what’s the difference between being feature-focused vs. vision-led? Do you have an example from one of your roles that illustrates this difference?

There’s a lot of content out there about the benefits of being vision-led. There’s also a large push toward this outcome versus output mentality, but the truth is that when you come into an organization as a product leader, you have to see where that organization is really at. There’s often a big difference between the theory of the situation and its reality.

I joined Going back when it was called Scott’s Cheap Flights. At the time, we had fairly immature engineering and product organizations. The group had done some great things, but they were still in very early stages. The desire to focus on features (or become a feature factory) was actually an improvement from where the company was at.

Say product/engineering is struggling to release features consistently. That’s the first problem you have to solve. If you jump in and say, “We’ve got to do outcome-based work and change everything,” that would likely slow everything down further.

In our case, our first goal was to create consistency around how we shape and deliver work. Once we had traction with that, we were able to say, “Hey, we can do this. We can absolutely ship consistently.” Then, we had the privilege to talk about what we were actually shipping and evaluate if there was an impact there.

How does that vary based on the stage or the size of the company?

When you’re trying to make that change as a product leader, whether you’re a CPO or a senior PM on a squad, it’s really just the scale that changes. As a product person, one cool thing that often gets overlooked is that you have a lot of autonomy. It’s a lot of work and demand can be high, especially if you’re in a feature factory. There’s a lot of intense reality to that. But, there are also moments when you can start pushing toward a vision.

One callout that I love by Teresa Torres is the idea that if you want to do vision-led work, it starts with you. You might be a product leader who has the agency to change the whole organization, but you might be an IC PM hungry for change. Once you get your squad bought into what you’re doing and they see the throughput of what you are focused on, that’s pretty rewarding.

I like to advocate for folks to start in whatever way they can and apply these things to their own work. Many people think they have to wait to get some position of authority to do vision-led work, but that’s not true.

Creating a table of ownership

As you moved into a vision-led model, what challenges did you encounter in creating teams that were aligned to that strategy?

One of the biggest issues that I don’t see a lot of folks talking about is what happens when you organize a team around steps of the customer journey or specific outcomes. When you do that, it becomes a lot harder to judge where existing features go. If particular improvements need to be made on certain features, you need to spend mental effort to determine who’s going to take that work.

It sounds simple, but for any product team, a percentage of its time is in operational or iterative work. There will always be those buckets, and you can spend precious cognitive bandwidth just trying to figure out how to allocate work.

What methods do you employ to make this process less strenuous and redundant?

I like to divide the application into parts and features and create a table of ownership. The one upside of having platform-specific teams — which I know is a legacy practice that many folks don’t do — is that it’s very easy to figure out how the work is divided. However, the downsides of this practice are much higher.

You want teams that can address a member’s problem or opportunity regardless of the platform, whether it’s a mobile or web app, or in our case, email. At Going, we span all three, so we want teams to be able to pick whichever platform they want to test and scale across whatever they think is viable. The benefits of having the outcome-based teams greatly outweigh the confusion about where items go.

As soon as I create a table and have those teams, I like to assign ownership areas based on which parts of the app I think they’re best suited to own. This gives us the best of both worlds. We don’t waste any cycles trying to figure out where this one thing goes and who’s going to own it. Previously, we’d lose time figuring that out. It’s just a waste of time that should be spent elsewhere.

When creating the table, do you ever encounter any issues getting buy-in from the team?

There would absolutely be problems if I just created that table and passed it out. I work closely with our product and engineering managers to create the table and avoid that problem. The only place where there’s some awkwardness is when two teams feel like they could own something. That is pretty common, so it’s important to remember where the baseline is. Having teams co-create is messy. If that happens, I’ll say something like, “Hey, three of you say that you own this, but that’s going to get complicated. It defeats the whole purpose of what we’re trying to do. Can we try another pass?” Bringing it up this way has been helpful.

With the table of ownership, teams aren’t wasting mental energy thinking about where the components go. If a team builds a new feature, they will own it. That’s its future.

Marrying quantitative and qualitative data

How do you encourage teams to look through the lens of the customer instead of just being focused on the product itself? Are there any techniques that you use?

All of my techniques are learnings from Bob Moesta and Jobs-to-be-Done (JTBD) workshops. I remember the specific graphic of someone looking through a keyhole, and this represented how product teams look at the customer. It goes into the whole JTBD theory and the idea that a product team is always thinking about the actual product. It’s what they do day in and day out, so it’s easy to lose sight of what actually matters to the customer.

At Going, we use opportunity solution trees from Continuous Discovery. We lay out the product outcome that we’re trying to achieve and which customer opportunities (pain points, desires) are best suited to achieve that goal. Those opportunities are all in the customer’s voice, so we actually pull from our member success team’s queue and use our customers’ language.

If we’re doing qualitative interviews with members, we take the time to understand their context. One particular anti-pattern that isn’t often talked about is the tendency for teams to crowdsource features from their customers. It’s an easy win for a product team to say, “Let’s open source our roadmap. Our customers will upload the features they want, and we’ll build them.” The problem is there’s a difference between what people say they want and what they’re actually trying to achieve. I always recommend Chris Spiek and Ryan Singer’s Demand Thinking episode on understanding “demand and supply language” when talking to customers.

When you’re going through that process and trying to avoid the upvoting of features, how do you get context? Do you lean on customer success for input, read through more qualitative interviews, listen to customer calls, etc.?

Yes, all of the above. I’m happiest when I can find a confluence between quantitative and qualitative data. I was talking to our head of data and analytics once, and we were discussing how it’s almost like qual and quant data are puzzles. Each puzzle is incomplete, but when you layer them and have a Z-index, you can stack them to better understand what’s happening. That’s how we tend to approach things.

We have seen some themes that come up in our research, so we try to take those themes and look at what’s happening within the product. Is this a lagging indicator or a proxy metric? We really try to understand if something is causal or not. Then, we’ll start making a bet on whether we can inflict that through changes. It’s important to marry quantitative and qualitative data.

Can you share an example of a time when you saw something in the data, investigated it, validated it, and then ended up adding that feature to your product?

When I first joined Scott’s Cheap Flights, there was an assumption that our product worked best for folks with lots of flexibility in their travel plans. I was a little concerned that this was something everyone agreed with but had never tested. I pushed back and asked, “Well, where’s the data for this? Has anyone actually substantiated this?” The answer was no. So, I ran a very simple survey within our onboarding experience to ask people if they were flexible or were looking for a specific trip (i.e., destination and time frame).

The answer was that yes, the product works best for people with flexibility. But interestingly, the majority of the folks coming in were looking for something specific. That was new data for us. All of a sudden, I saw an amazing opportunity for our company, which already had found product-market fit, to match our offerings to this newer need.

These are things that we’re still working on. This is a really powerful lever because we tested and affirmed that our assumption was true. Some might say that it was a waste of time, but often, these experiments answer questions you don’t even think to ask. Once I saw that we had a new opportunity to serve this cohort better, I realized how big of an impact we could make. It’s a great positive sign for us because there’s potential for growth there.

Instilling co-created product outcomes

What’s your approach to coaching your teams to better understand and respond to consumer demand, especially when you’re putting a new team together or onboarding folks to your team?

I’ve been fortunate to work with Hope Gurion on applying continuous discovery at Going. Customer discovery focuses on a lot of the core ways of working that Marty Cagan has been advocating for. With software being an ill structured problem, there’s no one right answer, and therefore, it’s a creative act. You need to have diversity of thought and a team that trusts each other. These principles are always necessary for me.

Especially for outcome-based work, opportunity solution trees are powerful because they force you to start with the product outcome you are hunting for. A product outcome is, essentially, a proxy metric that the squad/team can affect and change. There’s a bet between that proxy metric and moving some lagging indicator, which is usually some form of revenue. Giving teams the structure of a co-created product outcome, and then the opportunities underneath it, is the strongest way to make an impact.

Can you define the proxy and the lagging indicators and talk about how you distinguish between those when you’re looking at product success?

Proxy metrics, to me, are things that you can give to an empowered product team to work on. If you give a lagging indicator to an empowered team, you’re going to end up in trouble. I’ve seen a case where the CEO goes to their team and says, “You are empowered. I’ve read this book by Marty Cagan, it was awesome. You are all now empowered, right? Go do your thing. Here’s your goal: $30 million in annual recurring revenue.”

What happens is the team gets overwhelmed and doesn’t know where to start. They come back to the CEO and ask, “Could you give us a list of things that you think could be a good place to start?” The CEO is excited. They love contributing ideas. They create a big list of things that the team could start doing and give it to the PM. The PM then is like, “Don’t tell me what to do! How dare you?”

It’s a vicious cycle that repeats itself multiple times a day. The key to avoiding this is to figure out the metrics we think are going to ladder up to this larger revenue goal. Then, how do we build proxy metrics that we can give to the team? Those should be things that we can inflect. Ideally, it’s something that the team can move in isolation.

You’re looking for that logical correlation between metrics that move slowly and that the business uses to judge success, and metrics that move a lot faster that a team can leverage. Teams look to their proxies to ensure they’re on track for hitting the goals that the business wants.

What role does the product leader have in this particular process in terms of making an impact?

To be successful, the process has to be a co-creation between the product leader and the PMs. The last thing you want to do is assign somebody a goal that they don’t believe in. There’s an art and science to it. Some of these things are correlations, and they’re not 100 percent causal. There’s risk embedded in that relationship between a proxy and a lagging indicator. Some things are less risky than others, and some things are more clear.

Getting that buy-in and then seeing teams be successful is so rewarding. They hit their goal and then two months later you see the impact on the business in terms of retention numbers going up. When I’ve seen teams do that it was really fulfilling.