From Enterprise to Startup and Back: Pattern Matching Across Contexts

I spent two years at Pivotal Labs embedded in client teams across every industry you can name: retail, government, healthcare, fintech. The clients were different. The orgs were different. The constraints were wildly different. And every single one was stuck on the same three problems.

They built without understanding who they were building for. They tried to do everything instead of the right thing. They planned instead of shipping.

I did not name those problems at the time. I was too busy solving them one engagement at a time. But after 14 years and four distinct contexts -- Fortune 50 enterprise, defense software factories, seed-stage startups, and mission-driven nonprofits -- the pattern is unmistakable. The problems are universal. The constraints are local. And the best product leaders learn to read both.

The three universal problems

Discovery, prioritization, and delivery. Every team I have ever worked with has struggled with at least one. Most struggle with all three simultaneously.

At Kaiser Permanente, a $350M digital portfolio serving 12 million members, the discovery problem looked like this: teams built features based on stakeholder requests instead of user research. Annual planning forecasted an entire year of development in Q3 of the prior year. Success was measured by on-time and on-budget delivery -- not whether members used what was built. When I ran a Q1 Assessment across 70+ product teams, I found that discovery was largely technical. Teams investigated feasibility but rarely tested desirability or viability.

At U.S. Space Force CDD, the same problem wore different clothes. A 9-person civilian IT division supporting space launch operations had engineering teams stuck in months-long build cycles with no clear output. Multiple SBIR contractor partners worked in silos. The backlog was chaotic and the roadmap did not exist. But the core issue was identical to Kaiser: nobody had stopped to ask what users needed before deciding what to build.

At FLUXX Health, a seed-stage menopause education startup, the discovery problem was inverted. The founder understood her users deeply -- she was an OB-GYN who saw the clinical need every day. But translating clinical insight into product decisions required infrastructure the team did not have: personas, user research protocols, a prioritized backlog. The knowledge existed. The systems to act on it did not.

At B Lab, the nonprofit that certifies B Corporations, I found 55% of companies had not answered a single question in the SDG Action Manager. Only 9% had set goals. NPS was 26. The product team was organized around individual tools -- BIA, B Corp Directory, B Analytics -- rather than around the company experience. Teams had developed blinders to other parts of the certification process. Discovery was happening within products, not across the journey.

Four organizations. Four domains. The same problem: teams build without understanding who they are building for. The vocabulary changes. The root cause does not.

What enterprise teaches you that startups need

Startups worship speed. Enterprise teaches you that speed without rhythm is chaos.

At Kaiser, I learned the value of operating cadence. The EGLT model -- Experience Group Leadership Teams -- brought product, design, engineering, and delivery leads together as a single cross-functional unit. No single leader. Shared accountability across four disciplines: viability, desirability, feasibility of development, and feasibility of process. When the EGLT worked well, decisions moved fast because the right people were already in the room.

Startups rarely have this structure. At FLUXX, decisions sometimes stalled because there was no cadence for making them. The founder, the designer, and I would discuss a problem ad hoc -- in a Sunday morning call, a Tuesday evening work session, a Slack thread at midnight. When we established a consistent planning rhythm, decisions that had taken a week started taking a day.

Enterprise also teaches stakeholder navigation as a skill, not an obstacle. Startup founders often treat stakeholder management as corporate overhead they do not need. They are wrong. At Kaiser, I learned to navigate complex organizational dynamics -- aligning Medical Group leaders with Health Plan priorities, managing the tension between centralized strategy and decentralized execution. Those skills transferred directly to FLUXX, where the stakeholders were clinicians, patients, and a founder with strong clinical opinions. The cast changed. The skill set did not.

The third lesson: planning that accounts for organizational complexity. At Kaiser, I designed an L1-to-L4 OKR cascade that connected enterprise metrics to squad-level key results. The framework was heavy -- too heavy for a startup. But the principle behind it -- that every team should be able to trace their work back to an outcome that matters -- applies everywhere. At FLUXX, we used the same principle with a lighter-weight tool: a 360-degree Persona Activation Map that connected user personas to product features to revenue streams. The mechanism was different. The discipline was the same.

What startups teach you that enterprise needs

Enterprise teams plan. Startup teams ship. The difference is not philosophy. It is constraint.

At FLUXX, we shipped an MVP in under six months with a team of four: a founder-clinician, a product designer, a project coordinator, and me. We did not have the luxury of annual planning cycles or stakeholder alignment workshops. We had a Typeform, an AWS Lambda function, and a hypothesis about menopause symptom assessment. We shipped, tested with 25 early users, iterated, and shipped again. The quiz went through two major versions. The second version produced 800+ completions and a 38% reduction in abandonment.

That urgency is the most transferable thing about startup work. Not recklessness -- urgency. The discipline of building only what matters right now, because you cannot afford to build anything else.

At Space Force, I brought that urgency to a defense context. CDD's engineering teams had been stuck in months-long build cycles. We coached the Nimbus Weather eBoard team through Discovery & Framing, inception, and into an MVP cycle. The result: cycle time dropped from six months to two weeks. That was not a technology change. It was a permission change. The team had the capability to ship faster. They needed someone to show them it was safe to try.

Direct user access is the other startup lesson enterprise needs. At FLUXX, I talked to users constantly -- usability tests, quiz feedback analysis, Clinician Advisory Board sessions. At Kaiser, user access was mediated by layers of approvals, IRB-adjacent reviews, and organizational gatekeeping. The product coaching team spent significant energy advocating for direct user research as a right, not a privilege. Some teams had never spoken to a member directly. That gap explained a lot about the products they were building.

Budget constraints are the final startup lesson. At FLUXX, total project spend across all consulting and SaaS was over $200K -- significant for a self-funded startup, but a rounding error at Kaiser. That constraint forced brutal prioritization. Every feature earned its place. At Kaiser, teams with larger budgets and longer timelines often built more than they needed because the cost of building extra was invisible. Constraint creates clarity. Enterprise teams that artificially constrain their scope -- by timebox, by team size, by feature count -- consistently produce better products.

What defense teaches you that nobody expects

Defense product work has a reputation for bureaucracy. Some of that reputation is deserved. But defense also teaches lessons that neither enterprise nor startup contexts provide.

The first is working under real constraints. Not market constraints or budget constraints -- operational constraints. At Space Force, Operational Acceptance processes blocked production deployments. A weather app could not go live until it passed security reviews that were designed for weapons systems. We reformed the OA process for Nimbus, clearing a path to production without the traditional gate. That required navigating institutional politics, building trust with range management leadership, and demonstrating that modern deployment practices were compatible with mission safety requirements.

The second lesson is the value of ceremony done right. Startup culture dismisses ceremony as waste. Defense culture sometimes treats ceremony as an end in itself. The productive middle ground is ceremony that produces decisions. At Space Force, we ran Discovery & Framing sessions that looked like Pivotal Labs methodology -- user personas, journey mapping, problem prioritization, usability testing -- inside a military context. We facilitated inception. We ran demo cadences. The format was structured. The outcomes were real. The Nimbus team went from stalled to shipping in weeks, not because we eliminated ceremony but because we made it productive.

The third lesson surprised me the most. The talent inside government teams is extraordinary when those teams are coached rather than contracted at. At Space Force, the CDD civilians were smart, motivated, and stuck. They did not lack ability. They lacked a delivery model that let their ability produce results. I mentored a PM named Blossom through her first Discovery & Framing cycle. I watched engineers who had been building in isolation start pairing and shipping daily. The transformation was not about replacing government talent with contractor talent. It was about giving government talent the structure and permission to do what they already knew how to do.

The transferable sequence

I have changed contexts five times in 14 years. Each transition felt like starting over. None of them were.

The pattern that transfers most reliably is a three-step sequence. Start with the user -- learn what they actually need, not what stakeholders assume they need. Ship something small -- the smallest thing that tests your riskiest assumption. Learn from it -- measure the outcome, not the output, and adjust.

Context changes the vocabulary, the constraints, the stakeholders, and the timeline. It does not change that sequence.

The product leaders who struggle with context switches are the ones who bring solutions from their last context. The ones who thrive bring the sequence. They ask: who is the user, what is the riskiest assumption, and what is the smallest thing I can ship to test it? Then they adapt the execution to the constraints in front of them.

Enterprise, startup, defense, nonprofit. The problems are the same. The constraints are different. The sequence works everywhere.

---

I help teams find their footing regardless of context -- whether you are a startup building your first product or an enterprise trying to ship like one. Check out my portfolio for the full range, or let's talk about what your team needs.