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.