TBM 278: The Power of Firsthand Experience

I was having lunch with my product leader friend Carey Caulfield recently, and something dawned on us:

In the product world, we often forget how we came to “know” certain things. When someone doesn’t appear bought into a product-oriented way of working, it’s easy to chalk things up to mindset, intent, attitude, strength as a leader, etc. It’s easy to feel frustrated and not trusted.

But the answer is much simpler in most cases: they simply haven’t experienced certain things firsthand! What types of things? Carey and I brainstormed twelve things it helps to have seen firsthand for certain product concepts to sink in.

(An aside: I like to boost people when they start writing. Carey is shipping her first email newsletter tomorrow. Wouldn’t it be great if she woke up to some signups? Scroll to the bottom of her site and sign up for her first post.)

To “get” product, it helps if you have observed or were ideally directly involved in:

1. A launch that went completely flat—the classic “If we build it, they will come.” Granted, this happens often, so this experience alone will not persuade you to adopt certain practices (and may even convince you to pursue anti-patterns), but in combination with some of the other experiences below, it can help. A variation involves observing feature usage for a highly mature product and seeing how diffuse and sparse it is between personas.

2. A team hyper-focused on a problem hitting multiple dead ends before pivoting to something that works. In most corporate settings, teams are given a short runway, and you don’t get second or third chances. Watching a team persevere and eventually crack the nut encourages more leeway for experimentation and bumps in the road.

3. A product with (very) strong product/market fit. I was walking with my son recently and noticed a huge line. I asked someone in the line what they were waiting for, and they started raving about mochi donuts. Huh? “We’ve been coming back every week. It can take an hour, but it is worth it.” Donuts? When you’ve experienced the same thing with a product, it puts “good” products in perspective. You realize that people might even pay for something and use it without there being a sustainable, long-term value proposition and draw. A variation here is seeing something with strong PMF in one market ending up with weak PMF with another market. It’s an important lesson.

4. A product that “sold itself” and had organic adoption. Granted, this is possible in some domains and not others (and is by no means a prerequisite for success), but there’s something about being involved with a product that had a self-service motion that converted into paid accounts. It has something to do with that perfect overlap of usability, learnability, time to value, etc. PMs who work at companies with product-led motions tend to prioritize things differently when they move on to companies with high-touch motions. Once you’ve seen this, you can’t un-see it.

5. A good product become bloated, debt-ridden, hard to extend, and difficult to use after years of running a feature factory. Once you’ve seen this happen, you become much more disciplined about adding new functionality and can resist the lure of short-term gains (e.g., building things to close individual deals). It hits home once you’ve seen the walls come crashing down—teams at a halt, customers leaving, and competitors chomping at the bit.

6. Just how effective a group of developers can be when they have firsthand experience with a problem, are passionate about it, and ideally have direct access to customers with a problem (#8). In many companies, stakeholders experience developers at a 5/10 energy level. People chalk this up to their developers being uninterested and unmotivated. But seeing developers excited about a problem and able to ship without a lot of friction changes your perspective. 

7. A team in the early stages of an effort doing discovery, spikes, prototypes, thin slices, etc., instead of heavy convergent planning. In product development, planning looks very different. It is more divergent, active, and participatory. If you haven’t seen this lead to results, you tend to view this behavior as “weird” or “irresponsible.” “It doesn’t seem like they are committing to the effort! Where are the plans? It feels like unmanaged chaos!” Product is messy, and from the outside it looks weird.

8. An assumption about customer representativeness that was proved wrong. Classic examples here are “going up into the enterprise” as if enterprises are all the same, assumptions around different geographies, or assuming that buyers and users are motivated by the same things. Once you’ve seen this play out, you become more diligent about validating seemingly overlapping opportunities.

9. How certain things that feel like necessary tradeoffs aren’t tradeoffs. For example, if you’ve seen how quality can increase speed in the mid/long term, you are more likely to prioritize quality and taming debt. If you haven’t, you are more likely to fall into the trap of believing you need to trade quality for speed.

10. A team with direct access to customers (and frequent customer interactions) and how it increased decision quality and velocity. Without this experience, it is easy to rationalize how customer proxies might be “almost as good, or better because it is less distracting. It is intuitive to assume, “How hard can it be to work through the research team?” The difference is huge, however.

11. A team demonstrating “optimistic pessimism” and having an impact. I remember a marketing team member remarking that “product teams can be so negative and shoot down so many ideas!” That type of pessimism will likely get you typecast as “too negative” in most environments. The trick is if you’ve observed that level of pessimism paired with an optimistic bias for action and result. This polarity—skeptical, pessimistic, etc. AND optimistic, ready to keep trying, etc.—only makes sense when you’ve seen it pay off. The marketer continued, “But who am I to complain—the results are amazing!”

12. They observed how effective a healthy team with minimal dependencies, can be when aligned around the right domain/problem. Things click. There’s an order of magnitude less process overhead and waste. It’s not magic—it takes work and support—but a team in this state can go for extended periods without traditional upper-managerial supervision. You turn around a year later and are amazed when they list their accomplishments. Until you’ve observed this, you are likely to believe that frameworks, processes, estimates, etc., are what’s needed to keep a team on track (vs. context and aligned autonomy).

Why is any of this important?

When talking about product to people in your company, it is easy to get people to nod. Who doesn’t want better products? But without firsthand experience, it can be extremely difficult to work how you need to. Details matter. The trick is inviting those people into the process and giving them firsthand exposure—even if that means demonstrating how the features you shipped failed to hit the mark.

Remember that what you know or believe didn’t happen because of some magic spell.

You experienced things firsthand (even if those things were failures and false starts).