Why I Built FloFactor
My AI engineers got faster than I could.
I started building FloFactor because of a problem I ran into building my own products.
AI had changed what was possible in engineering.
Software could be built faster than I had ever experienced before.
But as engineering accelerated, I discovered something unexpected:
The engineering wasn't the bottleneck anymore. I was.
What AI made possible
AI could build remarkably fast.
I haven't personally written code in nearly three years.
I build with AI.
AI changed the way I built software.
And as the tools became more capable, I learned that they could produce remarkably sophisticated software, provided I could give them sufficiently precise intent.
The better the engineering became, the more obvious that requirement became.
If I wanted great output, I needed a great implementation plan.
And that started pulling me upstream.
The bottleneck moved
The problem kept moving upstream.
A great implementation plan requires a great product specification.
- 01Implementation plan
- 02Product specification
- 03Product understanding
- 04Product judgment
A great product specification requires understanding the product well enough to know what the specification should say.
And that requires something harder still:
You have to decide what should actually be built.
That was the realization.
Engineering was getting dramatically faster.
Everything required before engineering was not.
The bottleneck had moved from implementation to understanding, prioritization, and judgment.
When context exploded
Then the context exploded.
At the same time, the amount of product knowledge I was creating started growing everywhere.
- AI conversations
- Customer feedback
- User stories
- Research
- Product ideas
- Technical analysis
- Marketing discussions
- Specifications
- Documents
- Previous decisions
I might use one AI to think through product strategy, another to analyze a technical problem, another to challenge an assumption, and another to explore the market.
Every conversation created more useful context.
It also created more fragmentation.
All the information existed. But the product understanding didn't.
Holding it together
I became the system holding it together.
I had to remember what we had decided.
What customers had told us.
Which assumptions were still assumptions.
Which ideas conflicted with previous decisions.
What had already been built.
What still mattered.
Where the product was going.
And, most importantly:
What should we build next, and why?
The system of record was my head.
Meanwhile, the AI engineers were getting faster.
They would finish the work and, metaphorically, turn back to me:
Done. What's next?
And the answer might be somewhere across dozens of AI conversations, documents, customer insights, product decisions, research, and everything I had learned about the product.
That was the moment the problem became impossible to ignore.
Why existing tools failed
The tools I had started too late.
Issue trackers are good at managing issues.
Document systems are good at storing documents.
AI is very good at generating more analysis.
But my problem existed before the issue was written.
Before the specification existed.
Before the project had been created.
I needed a system that could understand the product before the work became a ticket.
A system that could bring together what we knew, preserve what we had already learned, surface what mattered, and help me determine which decisions actually required my attention.
I didn't need another place to store product work.
I needed a system that could turn product knowledge into product understanding.
What I needed
That's why I built FloFactor.
FloFactor is the product system I wanted while building with AI.
It brings together the scattered reality of the product and helps turn it into a living understanding of what is true, what has changed, what remains uncertain, and what deserves attention next.
From there, it helps carry decisions into the product specifications, technical specifications, and implementation plans AI engineers need to build well.
The goal is not to remove me from the important decisions.
FloFactor does the reasoning work required to bring the right decisions to me. I retain the authority.
The question that remains
Product has to become AI-native too.
Engineering has already changed.
Small teams can now produce software at a speed that previously required much larger engineering organizations.
But that advantage only compounds if product can keep up.
When your engineers can build almost anything, the defining question is no longer:
Can we build it?
It is:
What should we build next?
That is the problem FloFactor exists to solve.
Know what to build next.
See how FloFactor turns scattered product knowledge into the context, judgment, specifications, and implementation plans your AI engineers need.