Scaling the Product Function: What Changes When Teams Grow

By Mariana Abdala

Lately, due to an increase in layoffs and downsizing in the Tech sector, there hasn’t been a ton of discussion about scaling technology organizations, and yet there has been a gradual uptick in the number of Product roles opening up. The Product Manager role is no longer unique to tech companies and is increasingly becoming the role that is replacing Business Analyst, Systems Analyst, Project Manager, and Delivery Manager roles. This means that we can expect to see more Product organizations growing, especially as the role evolves into one that functions as a gatekeeper at the crossroads of Business, Engineering, and AI.

 Scaling a Product organization and maturing the Product role isn’t just about adding more people. It’s about changing how decisions get made, how information moves, and how context is preserved. What worked when the team was a few people in a room often breaks when the organization spans multiple squads or pods, Product lines, and time zones. Alignment becomes harder, decisions take longer, and the role of Product itself starts to shift, from builders and translators to connectors and enablers. The Product leader who once managed backlog priorities now shapes culture, structure, and governance.

The Shifts That Matter Most

From Ownership to Orchestration

A well functioning Product team is accountable and takes ownership. Each PM owns a problem space and makes rapid decisions close to the work. The value is speed. However, as teams multiply, that same autonomy can create chaos. Without shared decision principles, the organization risks building fast in opposite directions. We see this with our training and coaching clients who want to scale their Product organization by shifting from individual ownership to orchestrated alignment. This is more complex to navigate than it sounds. It takes more than rethinking the operating model.

What do we mean by “orchestrated alignment”.  This does not mean centralizing every decision, or reaching consensus with cross-functional teams. Instead, we can interpret it as standardizing and codifying how decisions get made: what the company optimizes for, which metrics guide trade-offs, and how context flows across teams. The maturity of a Product function is measured less by how quickly it acts and more by how consistently it acts in service of strategy.

From Conversations to Systems

In small teams, alignment happens through conversation. People talk daily, sync organically, and sense misalignment early. Once the team grows, that natural communication breaks down. Context gets lost in translation, and people start working from outdated assumptions. At scale, the conversation must be embedded into systems. This is where Product operations (Product Ops) emerges, not as bureaucracy, but as connective tissue. Product Ops enables rhythm and consistency: how data is shared, how planning cycles run, and how learning loops close. The irony is that great Product Ops is invisible. In our experience, when this shift works, what we expect to see is teams spending less time reporting up and more time shipping meaningful outcomes.

The Product Role in the Age of AI

AI has changed what scale even means. Tasks that once required a full team, such as competitive research, user analysis, idea exploration, or documentation, can now be accelerated or automated by AI. But the core challenge remains: judgment. AI can suggest, summarize, and simulate, but it cannot decide which trade-offs to make or which problems are worth solving. This evolution reframes the Product role. As AI augments execution, the Product manager’s comparative advantage shifts toward framing. The question is not how do we build faster, but how do we ensure what we build still matters. AI also pressures teams to get sharper about context management. When every team member can instantly access summaries, prototypes, and ideas, the differentiator becomes interpretation. The PM’s role is to connect pattern to purpose, to turn abundant data into directional insight. Forward-thinking organizations are already experimenting with AI copilots for backlog management, requirement drafting, and user research synthesis. Yet the ones that succeed are those that pair automation with increased human clarity. The Product manager of the future is not a project overseer but a meaning-maker, someone who ensures the narrative behind the work stays coherent even as “machines” accelerate the work itself.

The Takeaway

With just about every enterprise client we’ve served this year, we’ve observed that scaling the Product function is less about headcount and more about mindset. It is the shift from fast to scalable, from reactive to rhythmic, from individual intuition to collective judgment. And as AI accelerates execution, the role of Product becomes even more essential. The more the work speeds up, the more that organizations need people who can pause, interpret, and steer. I believe that Product leaders who embrace that duality of velocity and reflection build a strong team that can scale with purpose and confidence.

How to Build a Roadmap When Everything Feels Like a Priority

By Mariana Abdala

At many organizations, it's currently planning season, while for some folks, planning started back in July. Regardless of when planning and strategy sessions are scheduled, every product team eventually faces the same dilemma: everything feels like a "must have" for next year. Sales wants one thing, and it's for the largest account. Engineering has their list of KTLO work. Senior leaders just came out of a strategy session with a new set of 'big bets.' Customers, meanwhile, are asking for quick fixes to yesterday's problems. And of course, you as the PM also have some hypotheses you want to validate. When that pressure starts to build, take a pause.

A Moment for Reflection

In many cases, planning is happening without having a clear understanding of next year's budget. These questions might sound familiar: 'What can we afford?' 'What can we deliver?' 'What do we need to cut?' But the deeper question, the one that defines strong product strategy, is: What are we trying to learn next year? If the roadmap only reflects what's certain, it's a plan for maintenance, not growth. The goal isn't to reduce uncertainty; it's to make smarter bets within it. When everything feels like a priority, the best leaders don't rush to schedule and do it all. They slow down long enough to clarify what truly moves the business forward. That's the difference between a roadmap that plots tasks and one that shapes a company's direction.

The Real Work Behind a Product Roadmap

A product roadmap isn't a list of projects; it's a story about what the company believes will matter most over time. It reflects trade-offs, conviction, and timing. It's not about capturing every idea; it's about sequencing conviction. I say this in my trainings often: ‘your roadmap is your prioritization’.

One pattern I've observed in my experience as a Product leader and among our clients is that many organizations confuse visibility with alignment. When everyone can see the roadmap, they assume their priorities are represented and understood. But alignment isn't about including everyone's requests; it's about clarifying why some things make the cut and others don't. The roadmap translates the planning conversations, the ROI rationale, and what is deemed impactful enough that it is ‘above the line.’ This is where strategic storytelling enters the equation. The most effective product managers frame their roadmaps around a narrative that connects market signals, company strategy, and customer outcomes. They use the roadmap to say, 'Here's where we are placing bets, here's where we're building defensible moats, and here's why.'

Reducing Noise Without Losing Vision

The hardest part is saying no, especially to requests that are backed by powerful people in the org. One practical way to shift the conversation is to elevate the discussion from the feature level to the theme level. Instead of debating which features deserve a slot, discuss which problems deserve investment. Reducing churn among enterprise customers invites a different kind of conversation than adding new filtering capabilities to reports. Once themes are agreed upon, teams can apply structured methods like scoring frameworks or opportunity trees to translate strategy into action. Also, spoiler alert, this is not as smooth as I'm making it sound.

Visualizing Trade-offs

A good roadmap is a visual representation of judgment. Executives don't need to see every feature name; they need to see momentum, how initiatives move the company closer to its north star. This is precisely why the Outcome-based roadmap framework that I often cover in our trainings is so effective. The framework allows you to group work by themes or outcomes, and then code by impact, not by timeline. The purpose is to create a visual language for trade-offs: what we're doing, what we're pausing, and what's under consideration.

The Role of Cadence

It's difficult to remember this during planning season, but roadmaps are living systems, not quarterly documents, not annual processes. They should evolve as teams learn. Monthly tactical reviews and quarterly strategy resets keep the narrative fresh without whiplash. The most effective Product Managers will shop their roadmaps around, and they treat their roadmap as a communication system, not a standalone artifact. The rhythm of review is what keeps everyone aligned, even when priorities shift. In other words, calibration meetings, roadshows, monthly recurring reviews with stakeholders, or whatever you need to do to keep your roadmap up to date and informative. At WSI, all of us who were managing larger Product portfolios had bi-monthly meetings with our brand and marketing teams , as well as our CTO, and in these calls we could collectively review the roadmap updates and manage any friction or confusion in the moment.

A roadmap, like a product, improves through iteration. Its value comes not from predicting the future, but from creating a shared rhythm for learning and recalibrating together. When teams treat the roadmap as a living dialogue rather than a static plan, alignment becomes a source of focus and forward motion, during planning season and throughout the year.

I wish everyone luck as planning season hopefully winds down and budget conversations move foward.

Product Management Is a Team Sport

by Carolina Fernández Vallés, Head of Product

Product management thrives when treated like a team sport, where every role matters equally. Just as no player is above the team in football or basketball, no single function, whether product, design, or engineering, should dominate.

While much is written about product managers, far less attention is given to the full product team. If you have worked in a truly collaborative product environment, you know the magic. Achieving balance across disciplines is tough, and every company adapts its own model. But one thing is clear: strong team bonds drive success. I hope you get to experience building products with an authentic, unified product team.

Configuring a multidisciplinary team is always challenging. Many companies approach it from a traditional perspective, building RACIs and governance forums, instead of focusing first on what needs to be achieved and on shared success. Starting with what unites us, rather than what separates us, is my first piece of advice to ease these conversations.

Too often, product teams are structured based on the org chart. Instead, they should be built around the core elements that drive a product’s success. It must be valuable, viable, feasible, and desirable. This happens at the intersection of business value, user value, and technological value. From there, you can identify “roles” or domain areas and then assign names. One person may oversee multiple domains.

The time needed to reach agreement on team configuration will vary depending on organizational maturity, complexity, and hierarchy. I recommend making this step as lean as possible. The reality of product work will show you what you truly need. When people try to build overly abstract frameworks, the situation quickly becomes overcomplicated.

Once alignment is reached and the team is ready to start, the real game begins. There is always a period of testing and adjustment, especially if people do not yet know each other. I recommend colocating the team virtually, and physically when possible. I know it is not always easy, but when it is, having a common space with a visual dashboard and product KPIs is invaluable. It gives everyone, from stakeholders to management, a clear sense of what is going on. Kicking off the team face to face is fundamental. Let the team define its own values, behaviors, and objectives. Let them feel bigger than the sum of their parts.

Once you are underway, how do you get the best out of the team? How do you build real relationships?

Recently I listened to a podcast with Simon Sinek and Esther Perel on “what love life can teach you about work relationships.” In contemporary society, many people seek fulfillment and a sense of community at work, especially as other forms of community have declined in certain countries.

Over time, business has borrowed concepts from the world of relationships, words like trust, psychological safety, storytelling, authenticity, and combined them with key performance indicators, growth targets, and productivity metrics. It is no question that for teams to thrive, relationships matter. The quality of your relationships affects your happiness and ultimately your business results.

So my biggest advice is this: invest in your product teams, empower them, and protect them. Act quickly when you detect unhealthy behaviors or situations, because these will impact morale and, ultimately, your business metrics.

The Product Trust Loop 

by Sairam Rajagopal, Global Head of Product at Guidepoint

Trust is not just a motivational buzzword - it’s one of the most important currencies of human society. Our trust in each other has taken us from a species to a thriving civilization. 

In Product Management - trust is often the benefit of the doubt that you need to succeed. It’s equally important to remember that it can be squandered more easily than it is earned. We need to nourish it in a continuous, purposeful process. It is often considered a soft skill that is hard to teach. In my two decades in product building, I have come to believe there is actually an honest, systematic and intentional way to do this. In the Age of AI, “Building Trust” will be one of the key human superpowers. 

Let’s first examine the challenges we face, and the foundations we must lay - before we discuss the ‘how’ behind it.

The Challenge: The Erosion of Trust and Learning

Product organizations frequently face a breakdown in the relationship with users and stakeholders, leading to a "death spiral where users and customers lose belief if trust erodes." This erosion is often rooted in a failure of the organizational learning process, driven by several key factors:

  • Fear of Failure: In environments lacking psychological safety, teams are afraid to acknowledge, discuss, or learn from failure. Problems are hidden, blame is deflected, and failed experiments are reframed as successes to protect egos. This prevents the organization from learning and causes the same mistakes to be repeated.

  • The Survivorship Bias Trap: Teams and leaders often study successful products and companies, assuming their practices caused their success. This is an ok signal, but not a panacea. Blindly following “Spotify’s Agile process” or “Zendesk triple diamond” etc are a flawed approach because it ignores the countless other companies that followed the same practices and failed. OR the specific needs of our org in its stage of growth. I believe "success teaches you almost nothing" [ especially without proper context ] as it misses the critical lessons learned from what did not work.

  • The Paradox of Success: Initial success can make an organization fragile. It creates pressure to maintain the status quo, fosters organizational ego, and discourages the very experimentation and risk-taking that led to the initial success. As a result, successful companies or teams sometimes "stop learning “ because they think they’ve already figured it out. There are great examples of Orgs/ Products that lost their way because success blinded them or they just stopped learning and improving - e.g: WeWork, Skype

  • Misguided Execution: Without a culture of learning and trust, PMs risk becoming "mercenaries" focused solely on execution rather than "missionaries" who are "obsessed with finding the truth, identifying the right problems, solving them and telling compelling stories that convert skeptics into believers." This can lead to an irrational attachment to failing initiatives and a significant opportunity cost.

The Necessity of Psychological Safety and Truth-Seeking

To overcome these challenges, a fundamental shift in mindset is required, centered on creating an environment where learning is the primary goal.

  • Psychological Safety as the Foundation: Amy Edmondson, emphasizes that psychological safety is the essential ingredient for organizational learning. High-performing teams often report more failures "not because they fail more, but because they’re willing to talk about it." Psychological safety "isn’t about being nice. It’s about giving candid feedback, openly admitting mistakes, and learning from each other."

  • Reframing Product Work as Experimentation: To foster learning, all product initiatives must be treated as experiments. As Jeff Bezos is quoted, “If you’re going to take bold bets, they’re going to be experiments. And if they’re experiments, you don’t know ahead of time if they’re going to work.” Success should be measured not just by the outcome but by the quality of the experiment and the insights gained, answering three key questions:

    1. What did we Improve (or not)?

    2. What did we prove?

    3. What did we learn?

  • Embracing Truth on a Personal Level: Effective Product Managers must commit to brutal honesty and a willingness to admit mistakes. The goal is not to be the person with the best idea but, as one manager advised, to be "the one who can spot it." This requires PMs to not be defensive when challenged and instead embrace the truth, even when it requires admitting "I don't know" and committing to finding out.

  • Be prepared to Unlearn: Unlearning is one of the hardest things to do for the human brain. It does demand a lot of confidence and security to be willing to start from scratch. If you are accountable and vulnerable - unlearning paves the way to new absolute learning.

The Solution: A Framework for Building Enduring Trust

The Product Trust Loop is a virtuous, repeatable, proactive process for creating a powerful feedback loop with users and stakeholders.

The framework is built on three core stages: 1) Learning the Truth through a combination of empirical evidence and genuine empathy; 2) Creating Faith in the product's vision through compelling, authentic storytelling; and 3) Building Trust through consistent, transparent, and accountable execution. In an era where AI can automate data analysis and execution, mastering this human-centric cycle of empathy, storytelling, and relationship-building become the key strategic differentiator for an effective Product Manager.

Stage 1: Learn the Truth from Evidence & Empathy

The cycle begins with a genuine and deep understanding of the user's reality. This involves two parallel efforts:

  • Unveil the Truth with Evidence: Gather both quantitative and qualitative data to understand user behavior. This requires robust instrumentation and soliciting feedback from all available channels.

  • Understand User Perception with Empathy: Actively listen to user complaints, negative reviews, and detractors to understand their perception, especially when it does not match the data. The key is to treat perception as valid feedback and dig into the "why" behind it, which is often a result of miscommunication rather than malice.

The synthesis of empirical evidence and empathetic understanding creates a "shared truth" that resonates authentically with the audience.

Stage 2: Create Faith Through Storytelling

Once the shared truth is established, the next step is to build belief and buy-in through effective storytelling.

  • Build an Authentic Narrative: A story built on the shared truth feels authentic and credible, addressing both objective realities and user perceptions. This positions the PM as a responsive partner rather than a defensive operator.

  • Communicate the Vision: Storytelling allows the PM to "sell the future not just the product," helping users and stakeholders see the larger vision beyond immediate tactical changes. It provides context for the MVP and can bridge the gap between the current state and future potential.

  • Appeal to Head and Heart: A compelling narrative engages stakeholders intellectually and emotionally, framing the "why" behind an initiative in a factual but relatable way. This cultivates faith and transforms observers, sometimes even skeptics, into believers.

Stage 3: Build Trust Through Execution

Faith and belief must be solidified through reliable and transparent execution. Trust is ultimately earned when promises are kept.

  • Deliver on Commitments: The most direct way to build trust is to do what was promised, meeting user needs and achieving forecasted outcomes.

  • Maintain Transparency and Accountability: Keep progress visible, sharing both successes and setbacks honestly. When mistakes occur, they should be met with candor and a focus on solutions, not blame.

  • Adapt and Learn from Missteps: A setback, if handled well, can build trust. This requires communicating what was learned from the misstep and outlining a clear plan for improvement.

  • Be Consistent and Follow Through: Trust is accumulated over time through a consistent pattern of reliable execution. This creates a culture where follow-through is the norm.

The Loop

This multi-stage process is not linear but a continuous, virtuous cycle. Successful execution earns trust, which in turn encourages users to provide more candid feedback and evidence. This renewed evidence and empathy feed into a renewed shared truth, starting the cycle over and strengthening the relationship at each turn. The virtuous cycle goes:  

  1. Evidence & Empathy → Creates a Shared Truth

  2. Storytelling → Builds Faith

  3. Execution → Earns Trust

  4. Renewed Evidence & Empathy → Renews the Truth (and begins the next loop)

Trust building as a Human Differentiator in the Age of AI

This Trust Loop becomes an even more critical differentiator in the age of AI. In our AI powered future, AI will significantly augment and accelerate parts of the product development process, we have to own the core human elements that underpin this loop.

  • AI as an Amplifier for Stage 1: AI can supercharge the "Learn the Truth" phase by analyzing vast amounts of quantitative and qualitative data far faster than humans, identifying patterns, and synthesizing user feedback. The Human PM acts as the empathetic shoulder. The listener and curator of the Shared Truth.

  • The Human Core of Stages 2 & 3: The subsequent stages—creating faith and building trust—remain quintessentially human endeavors.

    • Storytelling: Storytelling is one of the "critical human superpowers in the Age of AI." Crafting a narrative that resonates emotionally, builds faith, and converts skeptics requires empathy, nuance, and strategic communication that is beyond the current capabilities of AI.

    • Accountability & Trust: Execution involves more than just delivering features. It requires human judgment, accountability for missteps, and the ability to build interpersonal relationships. Trust is fundamentally a human-to-human connection earned through reliability and integrity.

In a future where AI handles much of the mechanical and analytical "busy work," the Product Manager's core value shifts decisively toward our human superpowers & in orchestrating this cycle of trust. The ability to practice deep empathy, tell compelling stories, and foster genuine trust becomes the PM's most durable and valuable contribution.

This framework is one of the core ideas from my new book, Fragile: A Survival Guide for Product Management in the Age of AI. If you're ready to build a more resilient product practice, you can learn more here at fragile2fearless@gmail.com 



The Integration Project That Quietly Changed Everything

By Laura Cristobal Boyer, former Sr. Product Manager at 15five

Let’s be honest: integrations aren’t exactly the sexiest part of Product. But they might be the most underrated.

The most impactful project I’ve ever led started with a simple, frustrating problem: our integrations were broken. And it was costing us customers.

The Pain Behind the Promise

At the time, we were facing growing customer frustration around manual data entry. Even the companies that had some form of integration were dealing with brittle, limited setups that created as many problems as they solved.

Internally, it was worse: customer onboarding dragged on. Support teams were constantly dealing with sync errors. And engineering had become the unofficial integrations help desk.

Then we uncovered a staggering stat: customers without integrations were churning at six times the rate of those with them.

That’s when it became clear: this wasn’t just a backend problem. It was a retention problem, a scale problem, and a reputation problem.

Rethinking the Approach

I was asked to “fix integrations,” but I knew it had to be more than patching holes. We needed a foundation that could serve as connective tissue between our customers’ systems of record and our system of action.

Rather than building 30+ one-off integrations in-house, we partnered with a unified API platform. My team and I architected a system that could sync employee data, such as job titles, managers, and org structure, every 24 hours. It supported user provisioning, custom attribute mapping, and even historical data syncs for deactivated employees. The whole setup process took most customers under 15 minutes.

Admittedly, it wasn’t plug-and-play. Many customers didn’t have sandboxes nor clean data to work with. So we had to overcome these pain points. We built internal tools to support messy real-world scenarios and worked hand-in-hand with support, implementation, legal, and DevOps to roll it out smoothly.

Real Impact, Real Voices

Within a year, we had launched over 12 integrations, covering 90% of the HRIS platforms our customers used. The impact was immediate:

  • 60%+ of our customers started syncing data regularly

  • Churn dropped for previously at-risk segments

  • Support tickets fell by 50%

  • Time-to-value improved by 20%

  • Our win rate tripled among integration-ready prospects

Watching customer after customer connect their HRIS and say, “That was it?” felt like a huge win. Not because it was flashy, but because it just worked!

“This is the easiest integration I’ve done, congratulations there. It was pretty straightforward. The guide was step-by-step and amazing.” — HR Ops Leader, Financial Services Company (Workday)

“That was a lot easier than I thought. Probably one of the easiest integrations we’ve had. So that’s great!” — VP of People, Media Company (Paylocity)

“I went through the guide more than the video, just step by step, and it was self-explanatory for me.” — People Systems Admin, Tech Company (UKG)

We didn’t just fix a system. We gave our customers back hours of time and gave our teams a foundation they could trust. The integration became a pillar for performance management, onboarding, engagement, and retention, all because the right data was always where it needed to be.

Why It Mattered

This wasn’t the flashiest project I ever led, but it was one of the most impactful. It made the rest of the product better. It helped us operate more like a data-driven company. And it gave us a scalable path to delivering on our product promises.

And personally? It was a turning point. The success of this project led to several promotions and solidified my love for solving the kinds of messy, systemic problems that quietly change everything.

What I Learned About Building Integrations That Scale

For PMs who haven’t worked on integrations before, or who might be about to take one on, here are a few lessons I’d pass along:

1. Don’t treat integrations as just technical work.

It’s easy to think of them as back-end plumbing, but integrations directly impact onboarding, support load, retention, and trust. They are Product.

2. Design for flexibility from the start.

Every customer’s HRIS setup (or alternative tool) is different. Building in custom mapping, preview modes, and self-service capabilities early helped us reduce long-term complexity and support overhead.

3. Work closely with customer-facing teams.

Some of our most valuable insights came from support and implementation, (i.e., how many customers didn’t have sandboxes or clean data). These realities shaped what we built.

4. Integration UX matters more than you think.

Even the best technical system fails if customers can’t set it up. We invested in detailed guides and preview tools, which paid off in faster onboarding and fewer tickets.

5. Plan for maintenance, not just launch.

Integrations are not “set it and forget it.” We had to build tools for error handling, sync history, and field mapping updates, otherwise things would break quietly over time.

6. Treat vendor relationships like product partnerships.

If you’re using a third-party API provider, your success depends on their responsiveness, roadmap, and documentation. Choose carefully, and stay close.

I now run Lean Product Lab, where I partner with early-stage founders to help them unlock product-market fit, often by solving unsexy but critical problems just like this one. Because features come and go…but the right systems? They scale.

Successful PMs are Storytellers

Product Managers have to be storytellers, whether they realize it or not.

I'll never forget an experience at LendingClub during a company-wide Technology demo. I had to present a major initiative I'd been working on: introducing stronger MFA flows to protect customers from password stuffing attacks, phishing, and scams that put PII and sensitive data at risk.

When I shared my presentation with my manager, the VP of Product, his response was, "Mariana, you've been busy and done great work, but tell me why I should care." I was shocked. How could he not care? I had launched refurbished MFA flows for our most valuable customers, and one week post-launch it was reducing attacks by 98%. My InfoSec team was thrilled that I had successfully demonstrated efficiency gains and cost savings to senior leaders with our solution. So why was my presentation falling flat?

My manager said, "You need to make people feel things. Even your engineers. Make them feel scared."

I listened.

"Start this demo with, 'People are under attack every day. Have you been at risk of fraud? It's happening everywhere, and this is why LC customers need to trust us more than ever.'"

Aha. This wasn't just about showing UI screens and code or presenting next steps. It was about telling a compelling story of why the work matters. Because stories influence people's perceptions of your work's power, and if what you're doing matters, then you matter.

Every roadmap meeting, status update, or design kickoff is a chance to influence. To align. To inspire. But product narratives often fall flat when they get mired in feature lists, status check-ins, or technical details. It's easy for PMs to miss the bigger picture.

If you want to drive meaningful impact in a product organization, you must craft narratives that resonate across functions:

✅ Your engineering team needs context on why the problem matters

✅ Your design partners need compelling framing of the user's journey and friction

✅ Your business stakeholders need to see value in terms they care about: customer impact, revenue lift, retention, or strategic risk

Without influential storytelling, product work becomes transactional.

As a PM, you're uniquely positioned to own these narratives across functions. You become the connective tissue that makes cross-functional work effective.

AI tools can help. Today's Product Managers can use AI to refine, test, and elevate their communication:

🛠️ ChatGPT helps PMs synthesize insights into clear narratives, test variations for different audiences, and pressure-test the "why now."

📊 I like Claude by Anthropic for transforming data, OKRs, and long documents into digestible story arcs for leadership updates.

📈 Magical AI generates quick product update drafts and turns meeting notes into structured value reports.

🤩 Beautiful AI creates impactful, visually balanced decks tailored to various audiences.

Want hands-on help? I'm leading a live workshop on AI-powered storytelling for Product Leaders. It's designed to help you communicate impact, not just activity. $99, super practical, and built for working PMs.

🎟️ Reserve your spot here -> https://lu.ma/tpjr3jkh

We still have 13 spots left!

#ProductManagement #Storytelling #AItools #PMLeadership #ProductStrategy #Workshops

Move Fast, but Preserve Context: What CTI Taught Me About Product Strategy 

By Brian Warehime, CPO at Morado

When you’re building a product in the world of cybersecurity, especially in threat intelligence, you’re constantly straddling two opposing forces: the need to move fast and the need to preserve context.   

At Morado, our platform Threatnote helps CTI (Cyber Threat Intelligence) teams track intelligence requirements, collect findings, and produce actionable insights. But one thing that’s become crystal clear over time is this: intel without context becomes noise. And the same is true for product decisions. 

Why we built Threatnote

Threat analysts don’t just need to know what happened. They need to know why it matters, who it connects to, and how that fits into broader trends. They’re trained to document findings, cite sources, and leave trails others can follow. It’s a discipline built around maintaining context. That mindset has shaped how we built Threatnote, since we need to build thinking like an analyst and how they would utilize that context. 

In the early days, we moved fast, shipping features weekly and iterating in real time with users. But we learned the hard way that velocity without structure creates fragility. Features would get built, but a month later, nobody remembered the reason behind the decision. Worse, we risked breaking workflows that depended on assumptions long forgotten. 

So we adapted. Now we treat product decisions like intelligence reports.

  • We document the rationale behind changes, not just the tickets. 

  • We tag features back to customer problems or intelligence workflows. 

  • We close the loop by revisiting what we shipped and measuring whether it solved what we thought it would. 

We still move fast, but now we leave a trail. That has made all the difference as our product scales and more people join the team.  

If you’re building something complex, especially in a space like security or enterprise SaaS, preserving context is your multiplier. It helps your team build trust, stay aligned, and evolve the product without losing your compass. 

This shift in mindset didn’t just affect how we build, it changed how we communicate across the team. We started asking different questions during planning:

  • What’s the underlying problem this solves? 

  • Who will care about this in six months?

  • What assumptions are we making that might not hold? 

These questions help us avoid building features that are technically impressive but practically irrelevant. Context isn’t just a tool for analysts; it’s a safeguard for product teams against short-sighted decisions. 

It also forced us to rethink how we handle onboarding and knowledge transfer. As new engineers joined the team we realized that documentation wasn’t just for the sake of compliance, but for continuity. We started maintaining internal playbooks that explain not only how something works, but why it works that way. This helps new team members get up to speed faster and contribute meaningfully without fear of stepping on invisible landmines. 

Customer Trust is Paramount

Above all, we’ve seen how preserving context impacts customer trust. When users report bugs or ask for changes, we can point to the decisions behind a feature and explain our reasoning. Sometimes that results in better solutions. Sometimes it builds empathy. Either way, it shows that we’re listening, thinking, and evolving with purpose. And in a space like cybersecurity, where trust is everything, that matters more than you might think. 

This approach also influences how we think about technical debt. In cybersecurity, shortcuts can lead to blind spots. The same goes for product development. When we move quickly without preserving the reasoning behind a decision, we accumulate decision debt. That debt compounds over time, making it harder to pivot or scale without unintended consequences. By documenting not just what we built but why, we reduce that debt and make our product more resilient to change. 

Ultimately, building a product for intelligence teams means operating with a higher bar for clarity and accountability. Analysts are trained to challenge assumptions and seek evidence. That same discipline should guide product strategy. It’s not always about building faster, it’s about building with purpose, maintaining traceability, and ensuring your team has the context they need to make confident decisions. That’s what keeps us grounded as we keep moving forward. 

Harnessing Width and Depth: A Mental Model for Clearer Communication and Smarter Product Design

By Danny Rosen, Senior Technical Program Manager at Google

In the complex world of product development, communication breakdowns are common. Meetings can feel unfocused, documentation can be confusing, and stakeholders can walk away with wildly different interpretations of the same conversation. How can we bring clarity to this chaos?

The answer may lie in a simple but powerful mental model: thinking in terms of Width and Depth.

Originally spatial concepts, width and depth provide a framework for organizing our thoughts, structuring our communication, and designing our products more effectively. By consciously navigating between these two modes, you can ensure you're having the right conversation, with the right people, at the right time.

Understanding the Core Concepts: Width vs. Depth

Let's break down what these terms mean in a product context.

What is Width?

Width is about breadth and relationships. When you're operating at the "width" level, you are focused on the high-level landscape. You're identifying all the major components of a system and how they relate to one another, without getting lost in the details of any single one.

Think of it as the "what."

For example, if we were discussing a new to-do list application at the width level, the conversation would sound like this:

  • "The product needs a feature to create tasks."

  • "We need a way to view all the tasks in a list."

  • "There must be functionality to edit and delete tasks."

  • "This should be available on a website, and we should also consider a CLI (Command Line Interface) for power users."

Notice how each point identifies a distinct feature or platform. We're painting a broad picture of the entire product's scope, establishing the key pillars of the user experience.

What is Depth?

Depth, in contrast, is about detail and implementation. When you shift to a "depth" conversation, you pick one of those high-level topics and dive deep. You explore the nuances, the specific requirements, and the intricate workings of a single feature.

Think of it as the "how."

Continuing with our to-do list example, a depth conversation about the "create a task" feature might sound like this:

  • "When a user creates a task, what is the required date format? We need to support both European (DD/MM/YYYY) and American (MM/DD/YYYY) conventions."

  • "What are the precise validation rules for the task description field? Is there a character limit?"

  • "Let's define the 'snooze' functionality. When a task is snoozed, what happens to it in the data model? How is it triggered to reappear?"

Here, we've gone from a wide overview to a forensic examination of a single component.

Visualizing the Model: The Binary Tree and the Org Chart

A powerful way to visualize width and depth is by picturing a binary tree or a standard organizational chart.

Imagine a CEO at the top. That's the first level—the singular vision. Directly beneath the CEO are two Vice Presidents. These two VPs exist on the same hierarchical level; they represent the width of the organization at that tier.

Now, let's go deeper. One VP has three Directors reporting to them, while the other has six. We've just moved down a level, adding depth to the structure. Each of those Directors, in turn, has their own team, adding even more depth.

This tree structure perfectly illustrates the relationship. Moving horizontally across the nodes at the same level is a "width" action. Moving vertically down a branch is a "depth" action.

The Value of This Model: Practical Applications

Understanding this concept is more than a theoretical exercise. It has immediate, practical benefits for how you work.

1. Tailor Your Communication to Your Audience

One of the most common communication failures is a mismatch in altitude. The width/depth model allows you to consciously adjust your level of detail for your audience.

  • Executives & Sales: This audience typically operates at the width level. They need to understand the product's value proposition, its key features, and how it fits into the market. Drowning them in technical depth will only cause confusion and dilute the core message.

  • Engineers & Implementers: When speaking with the team responsible for building the product, you must be prepared to go deep. An engineer doesn't just need to know that there's a date field; they need to know its exact format, validation rules, and database schema. A high-level width conversation will leave them with unanswerable questions and block their progress.

  • Designers & UX Professionals: This group often needs to bridge both. They need the width to understand the entire user journey across all features, but also the depth to design the micro-interactions and detailed UI of a single screen.

By consciously asking, "Is this a width or a depth conversation?" you can frame the discussion appropriately and ensure everyone is speaking the same language.

2. Structure Your Thinking and Planning

The model is also a powerful tool for self-management and structuring your work. We all have limited cognitive bandwidth. Shifting between high-level strategy and granular detail is mentally taxing.

You can organize your time and effort more effectively:

  • "Today is a 'width' day." This is for brainstorming, roadmap planning, and identifying major epics. The goal is to explore possibilities and define the scope. If you feel yourself getting pulled into the weeds of a single feature, you can consciously pull yourself back up to the high level.

  • "This afternoon is a 'depth' session." This is for focused problem-solving. You're taking a single, well-defined problem and working through its implementation details, writing specifications, and answering technical questions.

This intentional focus prevents you from getting stuck in details too early in the process and ensures that when you do go deep, it's on a problem that has been properly contextualized by wide thinking.

3. Create Smarter Product Documentation

How you structure your Product Requirements Documents (PRDs) or project briefs can determine whether they are read and understood or ignored. The width/depth model provides a natural, intuitive flow.

  1. Start with Width: Introduce the product, the problem it solves, and the target audience. List the high-level features or epics that make up the solution. This gives every reader, from the CEO to the junior engineer, a clear overview of the project's goals and scope.

  2. Progress to Depth: After establishing the wide context, create separate sections that dive deep into each of those features. This is where you include detailed user stories, acceptance criteria, technical specifications, and design mockups.

This structure allows stakeholders to engage at the level they need. An executive can read the first two pages (the width) and understand the project, while an engineer can jump directly to the technical section (the depth) relevant to their work.

Conclusion: Your Framework for Clarity

The concept of width and depth is not complex, but its impact is profound. It provides a shared vocabulary to frame conversations, a mental scaffold to structure your thinking, and a logical blueprint to guide your documentation.

By consciously asking whether the moment calls for a panoramic view or a microscopic inspection, you can navigate the complexities of product development with greater intention, clarity, and control. It’s a simple model that, once adopted, will fundamentally change how you communicate, think, and lead.

Why I launched my own Product Consulting and Training Company

After nearly two decades in various Product roles building teams, launching products, and navigating the real-life messiness of tech organizations, I realized that I had basically earned myself a doctoral degree in organizational topology, digital transformation, and above all, Product Operating Models. Most of us don't have formal degrees in Product Management. Teaching Product at business schools has only emerged in the last five years, well after those of us in leadership roles today had to figure it out ourselves. We learned on the job, which is precisely why Product training programs are so appealing. But are they addressing the right challenges?

Most traditional options are expensive, bloated, and strangely detached from how work actually gets done. They're heavy on theory, light on nuance. And they often treat Product like a solo discipline, ignoring the critical role that designers, engineers, and delivery leads play in product success.

I've led product teams at fast-paced startups and large enterprises alike, across e-commerce, fintech, and edtech. I’ve watched incredibly smart, motivated teams get stuck, not because they didn’t understand a framework, but because they were operating in silos, misaligned on priorities, or buried under process that didn’t fit their context. And most of that is actually dictated from the top of the pyramid, so they can’t shift the way they operate overnight, but when you know the full context of the challenges, it’s easier to equip and empower those teams, while having productive conversations with the senior leadership who need to support the shift.

This is why I stepped away from the traditional training and coaching playbook and started something new.

At Product Advisory Studio, we design shorter, sharper trainings that are deeply embedded in the real-world context of the learner. Our sessions aren’t abstract lectures. They are working sessions grounded in your org chart, your sprint board, your stakeholders. And they’re aligned with the key changes we want achieve.

Our entire approach is shaped by real-time feedback from clients across finance, insurance, SaaS, e-commerce, and even government. We’ve heard their pain points, and we’ve built something that meets them where they are.

Effective training doesn’t just teach you how Product should work. It helps your team ship better, together, right now.

And that’s why I’m proud of the work we’re doing.

A mini case study: How we empowered a Product team through Practical Strategy Training

Old dogs can definitely learn new tricks. So can old SaaS teams.

Our work at Product Advisory Studio often includes working closely with product teams navigating growing pains, as well as mature teams experiencing sudden declines in performance and effectiveness. Before I started PAS, I noticed these issues were especially prevalent in teams you’d never imagine as having problems of this nature: well-established technology companies ultimately facing the pressures of transformation. One of my clients, a longtime leader in cloud-based data and analytics, was one such team.

Despite their technical depth and enterprise experience, the product team at this organization was struggling with a few common challenges we often see in legacy organizations: siloed work, misalignment between product and engineering, and difficulty translating business needs into actionable requirements. The result? A breakdown in trust between teams, a lack of confidence from the broader business, and a Product team that felt disempowered, with their hands tied when it came to releasing anything substantial or innovative.

After meeting with team leaders and stakeholders, I took stock of the problems they raised, and as I always do now, decided to craft a custom training program. Our engagement started with foundational upskilling, including practical techniques for prioritization, tailoring roadmaps for different stakeholders, and sharpening communication. But it quickly evolved. What began as a session on crafting product strategy became a deeper examination of how their strategy work was getting lost in a sea of outdated requirements documents- or simply skipped- leading to premature solutioning.

We introduced a simple but powerful tool: a living product strategy one-pager. It prompted the team to ask better questions upfront, including:

  • What is the desired end-state?

  • Who are we solving for, and why now?

  • What insights or data support this initiative?

  • What are the risks, and who’s accountable?

This wasn’t meant to be employed as a rigid template. Instead, it was a shared source of truth that brought product, design, and engineering together. By grounding each new initiative in business context and user pain points, the team finally had a framework that was adaptable, honest, and clear. This meant that solutioning was happening after problems were well articulated and feasibility was properly considered.

One of the biggest wins? The team replaced their legacy PRD with this strategy doc, and it stuck. For the first time, even long-tenured PMs said they felt empowered to lead from a place of clarity and cross-functional alignment.

I couldn’t be prouder of this team. The real reward for me has been seeing updates from the individuals who were in class: new promotions, fresh starts, and clever insights on how they’re now shipping better products with confidence.

We love doing this work. If your team is stuck in outdated habits and craving a more strategic, collaborative approach, let’s talk!

We Started Product Advisory Studio Because Product is Hard

After years of engaging with product teams, through their successes and their growing pains, it became impossible for us to ignore a pattern.

We would wrap up proposal calls with prospective clients, or walk out of client retros and have the same thoughts. It was clear that teams were stuck in an endless loop.

Smart, motivated PMs were doing their best, but struggling with silos, misalignment, and outdated ways of working. Too often, they were building solutions while missing the real problems, without a seat at the strategy table or support to grow their skills in meaningful ways.

Meanwhile, the training and consulting options out there weren’t helping. Theoretical playbooks, cookie-cutter frameworks, and instructors who hadn’t worked on product teams in years were available, and for a large price tag in most cases.

And in fast-paced startups? The gaps with Product, Engineering and Design become even more pronounced, and budgets are even tighter, meaning that support is even more out of reach.

So we decided to build something better. For a while it was Mariana in her corner, taking consulting projects ad hoc while maintaining a full-time Product leadership role, and for Brad it was running Enterprise Sales at Product School, thinking through how to realistically deliver training programs that companies were begging for and turning it into a viable business. Then, we joined forces!

We started Product Advisory Studio (PAS) as a boutique consulting and training firm for modern product teams because we believe there is an unmet need and Product organizations deserve better. Whether you’re a founder looking to define your product strategy or a product leader focused on team growth, we meet you where you are—with context, clarity, and momentum.

Here’s how we’re different:

  • Context-based training grounded in real-world challenges, not outdated case studies

  • Short, focused engagements that are additive and don’t pull your team away from their work for days

  • Hands-on consulting to align product, customer, and team strategy, especially during critical transitions and when finding PMF is time-sensitive

We especially believe in making our programs and engagements accessibile. Our work is designed for ambitious, scrappy teams, not just those with budgets.

Why Now?

Product is evolving fast.
Teams are leaner. Budgets are tighter. AI is reshaping the landscape. And yet, many product orgs are still stuck with one-size-fits-all solutions that don’t match the moment.

We’ve seen how undervalued and under-resourced product, design, and engineering teams function, and how much more powerful they become with the right kind of support.

Product Advisory Studio is our response to that need.
We’re not just trainers or consultants, we are practitioners. We stay close to the work, and that proximity sharpens everything we do.

Let’s Build Something Better—Together

We’re already partnering with founders and product leaders who want to grow their impact without wasting time or budget. If that’s you, we’d love to talk.

Whether it’s a strategy sprint or a custom training program, we’re here to help your team unlock what’s next.


Mariana & Brad
Product Advisory Studio

90 Days with Hansel: Lessons from the Frontlines of an Early-Stage AI Startup

 
 

Hansel.ai Has A Vision That Matters

Hansel, an early stay startup, is tackling a timely and urgent crisis: the epidemic of social isolation. Research from experts like Jonathan Haidt, Surgeon General Vivek Murthy, and Casley Killam shows that chronic loneliness is incredibly detrimental to our health, and can be more dangerous than smoking 15 cigarettes a day.

Hansel’s mission is ambitious and deeply human: to deepen real-life social connections through technology. 80% of people who heard even the first 20 seconds of the elevator pitch were wholeheartedly on board with the vision and mission.

At its core, Hansel is building an AI-powered “social secretary”: a lightweight agent that integrates with platforms like iMessage or SMS to help users turn intent into action. Whether it's planning a coffee catch-up or reconnecting with old friends, the agent is designed to make real-life meetups easier and more intentional.

The founder of hansel lives and breathes this mission. She has long rejected the culture of digital distraction, has been off social media for over 10 years, and has built her life around meaningful in-person connection. That ethos gives Hansel’s brand a rare kind of authenticity. Take note, founders!

The business model is equally thoughtful. While the product is intended to be initially free for consumers, Hansel will also eventually offer a B2B solution for teams and employers, basically positioning the tool as a social wellness benefit for workforces. After all, it’s been observed that people who get to know each other personally ultimately have more successful working relationships. A healthcare organization with 500+ employees even signed a letter of intent to pay $50 per seat—a strong signal of demand and viability.


When the Future Comes Too Fast

In Pattern Breakers, investor Mike Maples Jr. writes:

“To start a great company, you must live in the future.”

But many early-stage founders try to live in the future before validating the present.

When I joined Hansel as a product advisor, the tiny and mighty team had already invested in projections, acquisition strategies, and pitch decks. They had run a small survey (~30 responses) and conducted early user interviews that shaped the company’s messaging and made its way into pitch decks. A hard-coded prototype existed, but it was fragile and not yet usable for meaningful testing.

One of my first contributions was helping the founder define the MVP and stand up a knowledge base for a small tech team. We aligned on a product requirements document and a clear feature scope. But much of the company's energy remained focused on theoretical growth—CAC, LTV, waitlist conversions—rather than real product interaction.

As Lean Startup’s Steve Blank said: “No business plan survives first contact with customers.”

Validation doesn’t happen in spreadsheets. It happens through user behavior, feedback (quantitative and qualitative), and iterations.


What Was Missing?

The problem Hansel aims to solve is legitimate. The founder is deeply committed. The opportunity is real.

However, during my eventful and short engagement, the company had yet to build the product infrastructure to support learning or momentum (aka, Product-Led-Growth). A coded demo was built before any UI design work was done. It’s no secret that designs, including high-fidelity mockups, are typically faster, cheaper, and easier to iterate on than code. The founder had worked independently on this demo, and the backend was being hard-coded without prior discussion, in a vacuum, by former engineering colleagues volunteering their time. As new team members joined as partners, this approach felt neither transparent nor collaborative. The key gaps I started observing included:

❌ No testable prototype in the hands of users

❌ No continuous feedback loop

❌ A waitlist campaign without anything to adopt

❌ Conversations around CAC and LTV, but no real usage data

❌ A focus on finding a technical co-founder before defining the technical scope


These missteps are common, especially among founders with strong marketing or brand backgrounds who haven’t fully embraced what top voices and experts in Silicon Valley call the product discovery mindset. It was Marty Cagan who popularized this mindset among larger tech organizations looking to be more product-focused. I’ve seen these missteps occur in an almost repeatable pattern since I first joined a startup back in 2010.

Consider the power and the knowledge that comes from having users get to know your product.

“You can’t validate your idea without a product experience. And you can’t validate a product experience without users.” — Marty Cagan, Inspired

During my time working on Hansel, I was getting considerable pushback about addressing the gaps I mention above, and I actually assumed it was my own blindspots getting in the way. 

I also recruited a senior engineering advisor—a very accomplished individual I had worked with before—who dramatically improved the demo in only a couple of weeks. But his contributions went under-recognized. In retrospect, this reflected a broader challenge: the value of product and technical partners wasn’t yet fully understood.


Key Takeaways for Pre-Seed Founders

Building a startup at the pre-seed stage is an exercise in disciplined exploration. It’s easy to get swept up in the vision, the storytelling, and the strategies about how to acquire customers. But none of that matters without an existing product. What Hansel reminded me is that strong ideas need structure, and passionate founders need partners who can help them turn conviction into an actual product that can help you learn more about what your customers will ultimately need from you. Founders need Product people to remind them of the power of Product-Led-Growth. Here are the lessons I took with me—and the ones I now bring to every early-stage team I work with.

🛠 Build Before You Broadcast

This is the most important one. Don't build a funnel or grow a waitlist before you've built something people can actually use.

🎨 Invest in Product & UX Early

Hire someone who can prototype, test, and gather early signals before spending on paid marketing.

💡 Don’t Lead with CAC & LTV

Metrics are useful—but only after real usage exists. Strategy is not a substitute for signal.

🚫 Early Adopters Need Something to Adopt

A compelling vision is a great start, however you need a usable product to convert early interest into real feedback.

📈 Embrace Product-Led Growth

Skip the splashy launch. Focus on getting a few users to love your product and build from there.

👥 You Don’t Need a Technical Co-Founder (Yet)

You need someone technical enough to build, iterate, and learn with you. They should be local or timezone-aligned—not an offshore team taking orders from a non-technical founder.

🚀 VCs Want Proof, Not Promises

Especially in AI, healthtech, and cybersecurity, the bar is high. A beautiful deck won’t beat live user engagement.


Closing Thoughts

Hansel.ai is tackling a meaningful, modern problem with conviction. During my engagement, I saw the message sharpen and the ambition grow. I also witnessed familiar early-stage pitfalls—ones that can be avoided with the right approach to discovery and validation.

If you're building something new:

  • Start small

  • Build something usable

  • Get it into real hands

Live in the future, but validate in the present. That’s a proven way to build something that lasts.

What Is a Product Manager—and Why Your Startup Can’t Thrive Without One

Let’s pretend you’re the star of what critics are already calling the next big blockbuster. You’ve shown up every day: learning your lines, hitting your marks, going full glam in the makeup chair. The cameras are rolling, the lights are on, and the set is buzzing. But then it hits you: You have no idea who’s producing the film? In fact, you’re not sure there even is a producer.

You start to notice that some scenes feel off, others are electric, but no one seems to be steering the ship. No one's capturing what’s working, or fixing what’s not. And just when you think it can’t get more confusing—you realize you don’t even know who’s signing your paycheck.

No ask yourself, what are the chances this movie becomes a hit?

If you're building a startup, chances are you've got vision, grit, and a killer idea. Kind of like a Hollywood producer! You may even have a functioning prototype of your product. But if you’re missing a strong Product Manager (PM), you're likely missing the glue that holds vision and execution together.

Product Managers are the connective tissue between strategy and ship date. They don’t just keep the trains running—they make sure the train is going somewhere worth going, with passengers who actually want to be there.

🎯 Not a Feature Builder—An Ambassador of the Customer

Let’s get this out of the way: great Product Managers do not run feature factories.

They don’t just take orders from stakeholders or chase down every customer request. The most important contributions that PMs can make are customer-focused. PMs are relentless about understanding the customer—what they’re trying to do, what’s getting in the way, and what would make their experience better.

They balance stakeholder input with user research, behavioral data, and market signals. Because if no real customer wants or needs what you're building… what’s the point?

In other words: no viable customer = no viable product.

One of the reasons I love the Product-Led Growth mindset is because PLG turns real user value into your best acquisition engine. Unlike gaming a waitlist or chasing CAC hacks, PLG compounds—every great product moment becomes a marketing moment.

🧩 Alignment Is the Real (Hardest) Job

If there’s one thing PMs must do exceptionally well, it’s driving alignment across a cross-functional team. Getting people to disagree and commit, not by forcing consensus, but by guiding teams to agree to disagree productively, and still move forward.

Thinking back to our Blockbuster hit analogy:


The PM is the producer of your blockbuster product—managing timelines, talent, budget, and creative vision, all while ensuring the audience (or customer) loves the final cut.

🛠️ Translators of Vision to Execution

A great PM speaks both “engineering” and “executive.” They bridge the gap between customer need, business goal, and technical feasibility.

They translate abstract ideas into clear requirements that are influenced by:

  • Customer research and feedback

  • Business KPIs and strategic goals

  • Technical constraints

  • Competitive and market landscape

They don’t micromanage how the solution gets built—but they’re crystal clear on what and why.

📈 They Scale with Purpose

Launching a product is only the beginning. PMs know how to define and deliver an MVP, then scale it with purpose. They track the right signals, instrument the product from day one, and iterate based on real user behavior—not just gut feelings.

Because shipping your MVP and creating buzz don’t define success. Adoption and improvement do.

🧭 Ruthless Prioritization, Strategic Rationale

Every startup has more ideas than time. Product Managers are trained prioritizers—they make tough trade-offs, guided by both data and instinct. As a Product Manager, you need to know when to say “not yet”, “let’s put that on the back burner”, or “no” to features that don’t ladder up to agreed-upon goals. And they say it with empathy, clarity, and a plan forward.

🚀 It’s Not Just About Shipping—It’s About Launching and Landing

PMs are deeply involved in go-to-market strategy. They collaborate with marketing, sales, and customer success to make sure the product not only ships—but lands well. PMs should be conversations discussing the Go To Market plan. Why? Because they will need to align internal teams, craft clear messaging, and ensure feedback loops are tight so the product continues to evolve. Because success isn’t just usage—it’s engagement, love, and longevity.

So… Why Does This Matter for You?

If you’re a VC, technical co-founder, or visionary founder wondering why a product isn’t gaining traction, ask yourself:

👉 Do we have strong Product leadership?

Because tech without product is potential without a plan.
And vision without product is a great idea that no one ever uses.

Bottom line, if you want your startup to scale with clarity, speed, and customer love, then don’t build without Product.

My Top 10 Book Recommendations for Startups and Product Leaders

📚 Influential Reads to Help You Build Smarter, More Person-Centered Products

During my nearly ten years working at startups—ranging from seed to Series B—I hardly made time to read career books. After long hours at my computer or talking with colleagues in conference rooms, I usually chose to unwind with a good Pandora station or Spotify playlist. Eventually, I got into podcasts during my San Francisco commutes. But in hindsight, I wish I had spent more time with the books written by the people who shaped our industry.

There’s no better way to reset your mindset, unlock powerful insights, and find inspiration than by reading. Whether you're launching your first MVP, scaling a team, or trying to crack Product-Market Fit, the right advice at the right time can change everything.

As a product advisor and fractional CPO, here’s a stack of books I return to again and again—for myself, for my clients, and for anyone trying to build meaningful, successful digital products.

1. The Lean Startup by Eric Ries

I had the fortune and honor of having Eric’s team come to LendingClub and run workshops during my time as a Director of Product for platform services. The lean startup methodologies are timeless. This is the modern classic that introduced validated learning, the Build-Measure-Learn loop, and lean experimentation to a generation of founders and a massive generation of enterprises undergoing digital transformation. Still one of the best frameworks for reducing waste and building something people actually want—especially when resources are tight.

Great for: Founders, first-time builders, and anyone iterating on an MVP—even inside a Fortune 500.

2. Product is Hard by Marty Cagan

Silicon Valley Product Group hosted workshops for our leadership team at LendingClub in 2017, and I still refer back to those notebooks. This book is a no-fluff, candid set of essays from the legendary product thinker behind Inspired and Empowered.

Great for: Product leaders, startup execs, and founders scaling product teams.

3. Continuous Discovery Habits by Teresa Torres

Teresa Torres is a national treasure. Her book is a must-read for embedding discovery into your organizations. Torres makes a strong case for weekly touch-points with customers and shows us how to turn insights into actionable outcomes through one of my favorite topics to teach on:, the OST: Opportunity Solution Trees. I referenced many of Teresa Torres’ principles and teachings in my own lectures and workshops at Product School.

Great for: PMs, researchers, and cross-functional teams focused on learning and iterating.

4. Pattern Breakers by Mike Maples Jr. and Peter Ziebelman

I learned about this book at a Floodgate Ventures event. It’s a deep dive into how “thunder lizard” startups—those that fundamentally reshape industries—are built. My favorite takeaway? The concept of finding your co-conspirators who share your mission to reshape the future.

Great for: Visionary founders, early-stage investors, and product leaders building category-defining companies.

5. The Elements of User Experience by Jesse James Garrett

I often use this book in coaching sessions and UX workshops. It introduces the five planes of UX—from strategy to surface—and remains relevant across web, mobile, and AI-based experiences.

Great for: Product professionals collaborating with design or anyone needing a strong UX foundation.

6. The Field Guide to Human-Centered Design by IDEO.org

My introduction to IDEO's approach began back in 2009 at Tellme Networks. Their book and workshop materials were everywhere in the office and many of their principles guided the building and deployment of cutting-edge IVR technology that we were developing at the time for Microsoft. More than a book—it’s a hands-on, step-by-step toolkit for applying human-centered design in the field. It’s especially useful for teams doing discovery in complex systems, underserved markets, or social impact spaces.

Great for: Teams doing discovery in complex systems or building for social impact.

7. Fire: Inexpensive, Restrained, and Elegant Methods Ignite Innovation by Dan Ward

This is a favorite among scrappy product builders. Ward’s FIRE method—Fast, Inexpensive, Restrained, Elegant—challenges the idea that more time and money always lead to better products.

Great for: Lean startup teams, innovation leads, and anyone operating under tight constraints.

8. Bonus: Listen While You Work

If you're like me, juggling meetings, workshops, and long walks with the dog—consider grabbing the audiobook or Kindle versions. Many of these titles are available in both formats, so you can absorb wisdom while you're on the move.

💬 Let’s Swap Book Recs

Have a favorite product or tech book that changed how you build or lead? I’d love to hear it. Drop me a note—or reach out if you'd like a curated reading list for your product team.