Jon Sadow, co-founder and Chief Product Officer at Scoop, recently hosted an AMA with the Growth Masters community. The questions he received were incredibly varied, from more theoretical product strategy questions to in-the-weeds questions about Scoop’s analytics implementation. Read through the AMA transcript below to tap into Jon’s extensive knowledge about product strategy, growth, and carrier development. Plus, you’ll learn about his greatest piece of advice and lessons learned as a co-founder.

If you want more details on what’s discussed below, check out Jon’s Growth Masters lesson. Enjoy!

How did you come up with the idea for Scoop?

I have to thank my daily carpool commute with my older brother Rob (and fellow Scoop co-founder) to our high school in Atlanta for the idea for Scoop.

By the time I was 14, Rob and I were commuting 250 and 300 miles each week to get to school. 

Needless to say, I realized the pain and stress of a long commute early on, from planning my entire day around the drive to school to feeling drained before we even walked into class. Both my brother and I became well-acquainted with the toll such long commutes took on our physical and emotional health and sense of well-being.

There was one thing, though, that made it better: sharing that time with Rob. I had someone to talk to, debate sports, blast music, and talk about our days. The impact was real: it made all those miles seem shorter, and we’d get to school feeling just a bit happier and more energized.

That was just the start. I encourage you to read our story in Forbes to learn about our journey from ideation to launch! 

How involved is the Scoop product team in the overall growth strategy for the company?  

The Product team is involved in the overall growth strategy for the company, and it's important to call out that that's heavily influenced by the fact that I am one of two co-founders :)

So, that does, of course, make it much easier to ensure that Product is deeply involved (if not driving) the core growth priorities of the organization. 

But what really has unlocked that involvement by Product – and nearly every other team – is building an egalitarian culture. We've gone out of our way from day 1 to make sure we have cross-functional equality and appreciation. Our engineering team appreciates and cares about what goes into sales. Our operations team appreciates that we have to make hard prioritization trade-offs. We don't prop up one function as superior to the others. 

That level of appreciation and respect makes it natural for nearly all functions to be involved in our growth strategy and to collaborate naturally.

Are you using Segment only for tracking or also for building audiences (Segment Personas)? Can you mention some examples?  

We're using Personas! And we're super happy with it, especially paired with Sisense's Data Engine.

Between the two, we've been able to enable our Analytics teams to create transformed tables and then write queries against those tables to define segments in Personas. From there, we can trigger behaviors into our marketing flows and other in-app interactions. So, that's super powerful. 

Product strategy

How do you approach customer research? What is the most insightful thing that's come out of talking to/working with customers from a product perspective?       

We approach it in a few ways:

1.  Do a lot of it. Talk to as many customers as possible. That doesn't mean you should do what they say, but there is no downside in hearing them.

2.  Invest in user research from the very beginning. This was critical for us and is probably the most important suggestion I can give to any product leader at an early stage company. User research is fundamental, and the most important way to optimize your approach is to have great people on your team whose priority is that research.

Everything stems from these two ideas. Yes, there are meta points on disciplines, methodologies, etc. but if you do #1 and #2 correctly, those happen naturally. 

The best insights we get out of customer research come from understanding context and mindset. It's easy to say, "What do you want to do?" or "How did you like it?" It's much more insightful to understand what mindset they're bringing to the equation, what their normal behavior is, how they view change, who they are as people, etc.

Users and customers are people, and so the human context is where the magic lies.

What’s the best way to prioritize your product roadmap?   

I’m a believer that the most effective way to approach prioritization is to treat it like a religion, not just a process. 

When I first became a PM at Google, I was lucky to be taught and mentored by a guy named Paul McDonald, who led Gmail for a while, and has since left to start his own AI-vending startup Stockwell. 

He drilled into me that prioritization was everything for a PM and to be great at it, you had get comfortable scrutinizing yourself and your decisions. 

That’s a hard thing for people to do naturally. For him, it wasn’t the scoring, or ranking, or revenue projections that made the difference, but developing an obsession with ensuring the energy and focus was being put into THE most important thing. 

At Scoop, we’ve been most successful when we are maniacal about focusing on the one thing that matters most. Almost always, that’s whatever specific value we are trying to deliver to the user and why. Our best prioritization decisions have come when we challenge ourselves from all angles about how to realize that value. When we do that, we avoid falling into the trap of justifying a “nice to have” or, even worse, “an easy fix.” 

When we’ve struggled, it’s because we over-committed to a feature we added to the roadmap a long time prior, ignoring that the world around us had changed. 

As an organization, we’ve also really benefited from consistently inviting new instincts, user research, data, and healthy doses of pragmatism to challenge our priorities. And ultimately, we strive to stay extremely honest with ourselves about where the current product is falling short. That’s often the best indicator of where we should go next, and that humility is the best guiding light.

Looking back, if you could do one thing differently with Scoop in terms of product development, what would it be?       

If I could go back in time, I would have loved for our team to invest in our Customer Dashboard and insights platform earlier on. It’s been one of our biggest product team priorities for a few quarters, so we’re certainly making a significant investment now. But, as we continue to see how meaningful it is to our customers and Scoop’s growth, it’s hard not to wish we had this since day one!

Now, like most product people, I can (and will!) certainly make a good case for why we made the right prioritization choices at the time. After all, what’s unique about Scoop is our B2B2C model. The number one core value our customers get from partnering with Scoop is driven by the individual impact we have on their employees – the commuters. 

So, it was always easy for us to stay focused on the commuter side and put our resources and energy behind the Scoop mobile app. When we started Scoop 4.5 years ago, we were creating a new category, and our customers didn’t even know what type of product capabilities they wanted. As their needs began to take shape, we understood we’d have to invest in more product capabilities specifically for them - our stakeholders and buyers. 

But what I think we – or I – missed, was that it wasn’t just that we would have to build a customer-driven product. It’s that we would want to. I wish we had realized sooner that we could do a lot more than meet their needs. Instead, we could look to accelerate our ability to deliver even more value from Scoop via a customer-driven product.

Today, we’re antsy with tons of ideas of how to really empower the customer with full control and visibility into the impact Scoop is having and aggressively working to bring that to life! It’s exciting to see these ideas come to fruition. More than that, it’s a fulfilling feeling to know we are building a product rooted in Scoop’s mission to enrich millions of lives by helping our customers choose to make the commute a meaningful part of the day for their employees. 

What are the critical success measures that you use to measure your business? How have those changed as Scoop has grown?  

What's unique about Scoop is we are a SaaS business in terms of our customer orientation/business model/go-to-market. But, the end-user behavior we unlock behaves a lot like a marketplace. So, we have the fun challenge of measuring and tracking the performance and growth in both places!

In each category, our success metrics look a lot like what you'd see at other SaaS and Marketplace companies. On the SaaS side, it's a common mixture of top-line, efficiency, and sales productivity metrics. So, revenue, gross margin, CAC, annual revenue retention, etc. 

On the marketplace side, it's fulfillment rates, cancellation rates, user satisfaction, other liquidity metrics, etc. What you'll notice is our metrics aren't particularly unique - and that's by design. There are a lot of downsides when trying to come up with "special" metrics for your business. Sure, there are times where your business needs a different way to be evaluated. But the market is still going to evaluate against the comparable data in your industry/sector/competitive set. 

The more you have to "teach" an investor on how to evaluate your business, the more risk. So, in general, we don't try to over-complicate the metric types. Instead, we focus on which of the many types of SaaS or Marketplace metrics we are prioritizing from a growth/operations perspective.

As far as how these have grown since Scoop started, the biggest change is the emergence of our SaaS side. That wasn't always the core operating model, and as we've matured in our B2B go-to-market, our success measures have evolved in parallel.

What's the best way to get ahead of retention issues, and what are some warning signs you’d recommend keeping an eye out for?

1. Focus on delighting a core group of users before you scale. We often get excited about MORE users, but as we do that, their desires/interests become more diversified. Retention is just a reflection of how well you deliver what a user is looking for. The more types of users looking for more types of value, the more likely it is to under-deliver for some.  So, focus on the core segment, make sure you are listening and reacting to what can deliver for them, and grow out from there. 

2. Track it! Most products start tracking retention way too late, both in terms of the tools/attention, but also by looking at retention in months or quarters, and not weeks. Most retention curves break way earlier than we think.

3. Obsess over qualitative feedback as much (if not more) than quantitative. Retention metrics also push us toward volume feedback, data slices, etc. In the early days, you need to be getting (and filtering) as much feedback as possible. Hire a user researcher early on (or contract with one). Understand where expectations are misaligned (since that catalyzes churn). 

As far as warning signs, the best answer I can give is cohort data. I know that's not novel, but the signs of retention issues are retention issues - you just have to track and visualize them well. 

Did you ever discover a feature in your product that was instrumental in the product success; if so, how did you discover and track it, and what actions did you take after to develop it? 

The most applicable thing that comes to mind is an early feature we built called the “Community Map.” When Scoop first launched, the most common questions we had were around “Is anyone else on this thing?” That was logical, since we were just getting started and one of the hardest challenges in carpooling is the “first day” problem.

We decided to build a basic map to visualize the community surrounding someone’s home. The goal was really just to say, “Hey, look on the map, there are other people!” with the hope people would explore this and answer the question themselves.

They did! And people were visiting the Community Map. In fact, we found that nearly everyone was looking at it in their first experience, which was great. The unexpected consequence, though, was that it was creating a whole host of new questions.

The dots got them excited to learn more about who those people were. Did they work at the same place? Were they new to Scoop? How many trips had they taken? 

Based on this, we doubled down on the Community section and launched a big feature called the “People View.” This was a visualization of different “lists” of people in your area, including Co-Workers, Neighbors, new folks, and Favorites. This became so core to our product experience that we rebuilt our onboarding to frame the experience as “joining the community,” eventually landing them in the Community Map post-registration. As you might imagine, we’ve found that folks who interact with this section are far more likely to schedule a Carpool after registering. 

All because we wanted to try to answer an early question that flooded support!

Growing and scaling

What’s most important to keep in mind for onboarding?

There are certainly UX designers and experts who can give a much better answer here, so I want to start with that caveat. 

What I can share is that the most valuable thing we've done at Scoop is to approach the User Experience holistically -- starting well before the first screen of the app. The user journey is a long, complex one, and many companies/products make the mistake of only thinking about the in-app experience.

We've often said at Scoop that "user experience starts with the Scoop postcard someone receives in their building lobby and extends to interactions with our support team."

The point is that we tend to think that "experience" has to be physical. But what I learn about Scoop when I first become aware of what I see in the app store, to what I see in the app all influences my understanding of how Scoop works and how likely I am to be satisfied.

So, my suggestion here is to figure out what you believe a user needs to learn to be successful and then really thoughtfully map out WHEN and HOW they need to learn that throughout the user experience. Then you can create a "tour" that starts before they even open the app, and is reinforced through the in-app and out-of-app experiences they'll have.

How do you convince investors of a concept that’s proven elsewhere, but new in a particular area?     

I think it depends on where the investor is and what their investment thesis is. Smart investors are looking for market opportunities that they can appreciate. If the market opportunity is large and familiar, they'll be excited.

So you have to identify someone who understands the market (industry, country, culture, etc.), show that it's large, and prove (or give confidence) that you can conquer it. Not every investor will understand the market or care about it, and that's okay. 

Just remember the most important part here is "proving you can conquer it." If you can show that in a large market, you will ALWAYS find an investor who will invest.

What’s the best way to scale a two-sided marketplace?

The short answer is: figure out which has to come first and commit. It's nearly impossible to try to grow a marketplace in parallel from the beginning. You need to identify the constrained side of your market and do everything possible to invest against the experience quality and growth of that side. 

Uber did this better than anyone. They were obsessed with Driver supply in the early days and did whatever it took to make sure that they had enough Drivers to ensure the Rider experience was excellent. Once that experience was excellent, the rider demand grew organically (as we all know). 

So, you have to decide which is the naturally constrained part of the market.

We propel U.S military members' lives forward by texting them helpful information right when they need it. How many signups for my texting service would be meaningful enough to approach an angel investor to show market demand?        

First, I appreciate you putting your energy into thinking about how to support and serve folks in uniform. Not enough technologists think about how to serve these segments of our communities, and kudos to you for doing it!

I think what we're asking here is, "What does an angel investor need to see to get excited enough to invest?" Market demand is just one element of that, and showing market demand can come in many, many forms. 

Investors look to invest for a lot of reasons, and so it's important to remember that there's no secret answer here. 

The best advice I've received on this is to show "lines, not dots" to investors. This is especially true early on.

So what does that mean? A "dot" is a data point – some number of actions, users, behaviors, etc. But a dot has no context. We don't know if it's a lot or a little. And every investor, market, product, etc. will judge that differently.

A line connects to dots, literally. And so if I have a line, I can understand at least where we were and now where we are. That tells me a lot of things. It helps me understand trajectory. It helps me understand relative traction (vs. time, usually). It helps me orient toward the relative values that matter in this market. 

The best way to build buy-in from an investor is to communicate lines and bring the investor along as the line grows. Investors want to know that you can execute against what you promise/envision. So if you can say "Here's where we were...here's where we are...here's where we're going" and then SHOW them that you can get where you're going, they will believe in you. That is a HUGE part of the equation. 

In your case, I would push you to think not about "How many signups" but instead, how those signups (a) evolve over time, and (b) what underlying value that can be connected to (engagement, behaviors, etc.).

Career development in product

What advice would you give a PM on managing the teams they work with?  

Always communicate a clear long-term product vision to your team - and the entire company (or at least the organizations that surround you). I learned this lesson myself just last year. 

As the company grew up, I had started to take for granted the natural alignment between the company vision/mission and the product vision. Naturally, these are nearly indistinguishable in the early days of a startup. In the early stages, you’re only focusing on a narrow product scope, looking to understand if you can reach some baseline of Product-Market Fit. 

Once you do, your company shifts into its “adult” phase, which is about operations. And operating and scaling effectively means the number of areas of strategic investment grows too. Put another way, you have more people doing more things, and the core product vision you had early on (that you probably didn’t have to communicate as often) becomes outdated and unfamiliar to newer team members.

Also, I should note that the same thing applies to product teams at bigger companies, just in a slightly different form. Your product org, or pillar, or focus area has its own lifecycle. Teams grow, new faces come on, and the original mandate or organizational impetus for the product you’re working on changes. But it’s still your job to lead your team and collaborating teams in the right direction. 

As a product leader, it's easy to ignore the gap between what you have in your head and what has been communicated (and digested) by the team. I had a clear vision in my mind of where I saw Scoop’s products  going in the next five years. And it was even influencing near-term prioritization. But I took for granted that others had the same clear picture.

While some folks had lots of the pieces, I was overlooking the many different degrees of understanding, familiarity, and experience we had in a now much larger organization.

Fortunately, with some good pushes from our engineering leadership last summer, I focused in for nearly 6 weeks, and worked to capture that updated vision, socialize it, get feedback, and bring it to the company alongside our company Vision and Mission. The impact was immediate – and really powerful. It’s been ~1.5 quarters since, and it’s become fundamental – in large part because we’ve really communicated and referred back to it over, and over, and over. Now it's the foundation for our quarterly planning, roadmap development, and even our operational priorities across the organization.

What is your biggest mistake so that we all can avoid it?      

Ha! I would love to help everyone avoid some of the mistakes we've made ;)

The biggest product-related mistake(s) I've made have to do with "commitment bias" or the sunk cost fallacy. 

It's natural for us to envision features/capabilities we really think should be built next or down the road. But a lot of the time, our world changes by the time we get there.  We make the mistake of holding onto what we had prioritized before. We've had this happen a few times, and in retrospect, we should have stepped back and reprioritized. We shouldn’t allowed ourselves to be emotionally invested in something just because we thought it was the right answer a while back.

What resources would you recommend for a new product manager?

Great question.

The most important resource I'd recommend is to find a mentor. There are a lot of obvious reasons why this is valuable, but specifically, the upside is having someone who sets a baseline for you as a Product Manager.

What do I mean by that? There are MANY different ways to be a great PM and many different underlying skill sets that lend themselves to being successful. There's no one way, and that's why there's tons and tons of content that will tell you hundreds of different "must-have" approaches and skills.

The reason a mentor is so valuable is it's a forcing function to start building your Product Management philosophy off of the mentor as an archetype. It allows you to have a starting point for what you think "really good" is, and then adapt/evolve/build on top of that. It doesn't mean you should aim to do everything they do, but you can let them create the foundation or baseline, and then grow from there.

If you don't have that mentor or are still searching, I'd encourage you to try to build the same baseline regardless. You can do this a few ways:

• Pick a product person who you want to model after, even if you don't know them! Find someone who has written/shared a lot, identify their philosophy as a baseline, and work from there.

• Irrespective of your limited experience, just set your own baseline based on the best PMs you've seen and your gut. For one, you'll want to get good at sharpening your gut/instincts as a PM in general. But beyond that, you can still have an initial POV on what great PMs do, and then build off of that.

The reason I give this strong push around baselines is because the risk of so much content is that you can be unfocused on what you're trying to optimize for and how you're looking to grow. The critical thing early on is to sharpen one core competency after another, and so that baseline/archetype will force that discipline and prioritization.

If you want exclusive access to AMAs like this in the future, sign up to the Growth Masters community today.