ProcessFlow

This was our first real product. We were a team of 3 co-founders: a Design Engineer, a full-stack SWE, and me as Product Manager. We started ProcessFlow in December 2024 and worked on it for about a year, incubated at Station F in Paris. We were targeting ops teams at small and mid-sized businesses who needed to standardize their operations.

As PM, I owned the product strategy, led discovery calls, defined the ICP, scoped features, and drove go-to-market efforts including a trip to San Francisco to observe a potential client's operations onsite.

We saw teams stuck between two bad extremes: static, text-heavy documents (Notion, Confluence) that completely fail to capture branching logic, or infinite-canvas visual boards (Miro) that quickly devolve into overwhelming spaghetti diagrams. Documentation was always outdated, onboarding was slow, and all the knowledge lived in people's heads.

We built an interactive, node-based builder designed for clarity and ease of use. You could add conditional logic, embed the flows directly in Slack or Notion, and teams could standardize their operations in minutes instead of writing 10-page docs nobody reads.

Structured visual builder. Using React Flow, we built a canvas that let users map out branching steps intuitively. Instead of an unconstrained infinite canvas, we implemented explicit, guided UI dropdowns for adding steps, delays, and conditional logic. The goal was always: complex workflows, zero visual chaos.

We got 70 users and got accepted into the 42 incubator program at Station F. But we never generated revenue.

By July 2025, I was running discovery calls and got invited by a CEO to visit their company in San Francisco to observe their operations onsite. During that visit, I discovered their actual pain point wasn't SOP documentation at all, it was sales team training. We immediately paused ProcessFlow and built them a custom AI Sales Training pilot in just 10 days.

After two months of pilot negotiations, the SF company delayed implementation by six months due to internal timing. That's when it hit us: B2B sales cycles are grueling, and as young founders without an established corporate network, closing enterprise deals was nearly impossible. We decided to sunset our B2B efforts and pivot to B2C, which eventually became Lume.

As a team, we fell into the classic startup trap: we built a complex tool based on our own assumptions rather than confirmed market demand. We thought we understood the problem because it seemed obvious, but we never properly validated it with real users before building. We over-engineered the interactive builder before checking if companies were willing to pay for it.

I also realized that B2B SaaS is uniquely hostile to young, first-time founders without an existing corporate network. Enterprises are inherently risk-averse. They don't want to be the guinea pig for an unproven startup. Cold outreach barely works. You need warm intros.

• Validate before you build. No matter how clean the architecture, you must validate the problem with the target audience first. We should have done 50+ discovery calls before writing a single line of code.
• Monetize the problem, not the code. Sell the solution before building the product. If I started over, I'd focus on distribution first (getting access to the right people) and only then figure out what to build for them.
• B2B sales cycles kill startups without runway. Enterprise deals take months of negotiations, and one delayed implementation can end you.