A conversation with Jeff Clark

Jeff, you’re passionate about product discovery. How did you first get started, and when did it click for you?

I’ve made so many bad product decisions in my career. And 99% of the time it was not only because we were building the wrong thing, but worse: we didn't understand who we were building for.

And looking back that's pretty embarrassing, because what we were missing was simple: it starts with having real conversations with real people.

When I started in product, I was just so excited to build. I'd come up with this great idea and just pour my heart into making it come to life. I thought the hard part was bringing it to life. The first time I fell into that trap was back in college when a friend and I built the official student portal for Oklahoma State. We thought it was great, but just got zero usage outside of people checking their email. And you know what? We kept working on other projects and making that same mistake.

The first time it clicked happened by accident in the late 2000s. I’d built a photo-sharing app – again with that same friend – and it took off. It was a social game so we ended up talking to a bunch of early users about new features we were planning, and we stumbled into understanding why they were actually using the app. Hint: not why we thought. And so we stumbled into a solution that resonated with folks, without understanding the problem we were solving.

We ended up taking those learnings and for the first time felt we had a true guiding light – their unmet needs.

So the first time it clicked was by accident. If you hadn’t stumbled into a successful product, you wouldn’t have been able to work backward to the problem you were actually solving. Did that change the way you approached product from then on?

Absolutely. Yet there was still much more to learn. Later, I joined Hudl, an ambitious sports hardware and software performance offering for coaches and players.

While there, leadership approached me with an idea: by leveraging recent advancements in hardware and AI, we could create a 'connected gym' that allows coaches to focus on coaching and players to focus on playing, without having to worry about the technology behind the scenes. The concept involved more than just automated sports film recording; it had the potential to control the scoreboard, lights, and everything else inside the gym.

So we built a proof of concept for field hockey games to demonstrate its feasibility. From there, I conducted early discovery sessions with coaches and athletic directors to gauge their interest in a 'connected gym'. They were into it! But hardware (and time) are expensive, so we needed more evidence before fully committing to the project.

That's when we shifted to pre-selling using a letter of intent. Suddenly, the priorities of athletic directors were drastically different than in early discovery. It became clear that their main need was to automatically capture game and practice footage. If we couldn't nail that, none of the other parts of our "connected gym" would matter at all.

We ended up with a product that took competitive sports by storm - there are tens of thousands of these cameras out in the field now. And it was only possible by pitching an early version to actual buyers and learning where we were wrong. So much of that work happened out of the office. It wasn't with engineering, it wasn't with sales, it was with our future customers.

That’s awesome. What other advice do you have for product managers who are just getting started with discovery?

Exactly that – just get started. There are infinitely more resources available than when I got started to learn about customer interviewing and user research. Most PMs don’t have the luxury of learning from a dedicated researcher and that’s fine. What we’re doing isn’t rocket science or cancer research. And sure you’ll make mistakes, but my advice is simple: just get started. Start talking to your users every week and learn about them. And you’ll realize you’re already making better product decisions.

The highest performing teams I’ve been on have been ones where engineering is involved in the discovery process as well. I think there’s this stigma that it has to be the researchers, or has to be the designers, or has to be the PMs, but it’s not that hard. If you need to know something, you just go talk to people, regardless of your role. And if you care about making great products, you need to go talk to the people who will buy or use them.

Let’s fast forward to today, to your role at Appcues. What are some of your more recent learnings around product discovery?

The more successful your product, the easier it is to fall back into the trap of believing your organization has all the answers. We have so much feedback coming in from our customers through sales, support, and even directly through our own feedback collection tools. Most sales and success conversations with customers are even recorded, so the product team has the luxury of just searching and jumping into those when we need to.

But there are two problems with this passive approach:

1. You can't trust the transcript at face value. Not because the transcript isn’t accurate. But because without hearing the context, the tone, you’ll misunderstand what they’re saying or why.

2. Unless you have enough further evidence to take it at face value, you have to talk to that customer directly before making a product decision. Treat the passive feedback as an invitation for more details about the problem, what they’ve tried already and why it’s not working.

The only reason an experienced product person wouldn’t do this is if it’s too painful or time-consuming to get that person into a call. And that’s a terrible excuse.

It sounds like you’re saying recruiting for customer interviews is still an unsolved problem?

Haha, I fell into that one. Yes – 100%. The most painful part of discovery is getting people on the horn and scheduling time with them.

I would say the second hardest part is sharing the insights with other people that weren't there. Not giving them some bulleted list, but enough of the context that they don't have to go watch a whole interview or read a long report to get the takeaways from it.

I'll send you a check after this. Thanks so much for your time, Jeff!