Demo persona

Sam Okafor — Mid-career founder of a failed agritech startup

Spent five years building an agritech startup that connected smallholder farmers to buyers. It shut down last year. Now looking for a product role where hard-won lessons count.

  • Goal Assess fitness for a specific role
  • Role context A general role for ongoing applications
  • Interview style Structured HR interview

Sam completed a structured, roughly 35-turn interview about how he built, decided, and failed as a founder — measured against a general Product Manager role for ongoing applications.

Choose whether to open the saved sample immediately or run the current Railway inference stack over this persona's transcript and documents.

Uses the live models. The first run can take several minutes.
View saved sample Instant precomputed report for presentation use.

Evidence this persona provided

Copy-pastable — drop these into the normal chat / analyze flow if you want to run the pipeline yourself.

Cover letter

Portfolio

Target role context (A general role for ongoing applications)

This is the "assess fitness for a specific role" input — it feeds the CCI's Task-Entropy grounding and role-fit read.

Simulated interview transcript (70 turns)
Thank you for coming in, Sam. I'd like to work through your experience systematically. To begin, could you describe the core of what you did as a founder?
At the core I decided what we built and why, then made sure reality agreed with us. I did sales and ops early too, but the through-line was product judgment — choosing the few things worth doing with almost no resources, and killing what felt good but didn't move the business.
Who were your users, and how well did you know them?
Smallholder farmers, many of whom couldn't read our app. I spent real time in fields watching them, because you cannot understand that user from a desk. I learned the actual product wasn't software — it was trust, and everything followed from getting that right.
Let's take a concrete decision. Tell me about a significant product call and how you reached it.
The biggest was pivoting from a marketplace to a logistics-first model. We'd assumed farmers needed help finding buyers, so we built matching. But watching transactions, deals were dying at transport — produce spoiled before it moved.
What evidence convinced you?
Matched deals had about a forty percent completion rate, and nearly every failure traced to logistics, not matching. The data and what I saw in the field pointed the same way, so I stopped trusting our original assumption and followed what actually broke.
And the outcome of that pivot?
We built pickup scheduling and a small transport network instead of fancier matching. Completion jumped and transaction volume roughly doubled over the next year. The lesson stuck: watch what breaks, not what you assumed people needed.
How did you prioritize with more to do than capacity?
I forced everything through one question — what will change the number that matters most this quarter. With two engineers I couldn't be fair to every good idea, so I kept a visible ranked list and said no to a lot, including things investors asked for.
How did the team react to those no's?
Better than you'd think, because the ranking was explicit and they could challenge the logic. When people understand why something lost, they disagree productively instead of feeling arbitrarily overruled. Transparency made the no's survivable.
You've been candid that the company failed. Walk me through what went wrong and your part in it.
We died on unit economics. Every transaction quietly lost money because our logistics costs never scaled down the way I told myself they would. It wasn't a demand problem — it was a viability problem I refused to see.
Could you have seen it earlier?
Yes — I had the data at least eighteen months before the end. But I was intoxicated by usage growth; forty thousand farmers felt like proof. I optimized the metrics that flattered us. My failure was discipline, not information.
How did that change you?
I now distrust any metric that isn't tied to whether the thing is actually viable. The first question I ask of any product is 'does the money work at scale', not 'do people like it'. Liking something is necessary but nowhere near sufficient.
How do you typically work with engineers and designers?
I bring them the problem and the evidence, not a pre-baked solution. My best result was sharing the farmer interviews and letting engineers design the USSD flow — it was better than anything I'd have specified. I own the what and why; they own the how.
How do you protect a team from churn?
I absorb the noise. If priorities shift or an investor panics, I don't pass every mood straight to the team. I translate it into at most one clear change, or I hold the line. Shielding their focus was part of my job, not a favor.
How do you decide when the data is thin or contradictory but a decision is due?
I size the bet to my uncertainty and look for the cheapest experiment that turns a guess into evidence — a fake door, or doing the thing manually before building it. When unsure farmers would pay for transport, we brokered dozens of trips by hand first.
Why manual first?
Because a week of spreadsheets and phone calls taught us more than a month of debate or a quarter of building. I'm comfortable deciding under uncertainty as long as the decision buys information and isn't a one-way door I can't walk back.
Tell me about a time you had to influence someone senior or an investor.
An investor wanted us to add a flashy consumer app. I disagreed, so instead of resisting emotionally I ran a small test that showed our farmers wouldn't use it. Data beat opinion. Bringing evidence rather than defensiveness is how I win those conversations.
What environment brings out your best work?
Close to real users and real constraints, with enough autonomy to chase the actual problem. I'm energized by messy, operations-heavy products where the answer isn't obvious from a slide deck. Proximity to the customer is oxygen for me.
And what wears you down?
Politics disconnected from users — decisions made to satisfy someone's ego rather than the customer or the numbers. As a founder I had total context, so my worry about a big company is losing the direct line to the user.
How would you guard against that at a larger company?
I'd insist on talking to customers directly rather than only reading someone's summary. Even a few calls a week keeps my judgment honest. Secondhand user understanding decays fast, and I've seen good teams drift because of it.
What have you learned about yourself as a leader?
That my instinct to move fast has to be balanced by inviting dissent. My best decisions came when someone felt safe telling me I was wrong. I now actively ask 'what am I missing' rather than assuming my conviction is enough.
How do you handle being wrong in front of your team?
I say it plainly and early. Hiding a bad call costs far more than admitting it. When I owned the unit-economics mistake to the team, it actually rebuilt trust, because they'd already seen it and were waiting to know if I had.
Where do you think AI changes product management?
It speeds the mechanical parts — summarizing research, drafting specs, mining support tickets for patterns. I use it to compress busywork. But it can't decide which problem deserves the company's scarce attention, or hold the human context of a tradeoff.
So where does that leave your value?
Further toward problem selection and stakeholder alignment — the judgment rooted in talking to real people. I'm happy to let tools do the drafting and analysis I used to do by hand, and spend my attention on what actually matters.
What kind of product domain would you most want to work in?
Something operational and real-world — logistics, fintech for underserved users, marketplaces. I'm drawn to products where the messy physical or financial reality is the hard part, because that's where my field experience and failure actually pay off.
What would you need from a manager to do your best work?
Clear outcomes and the trust to figure out the how, plus honesty when I'm off track. I don't need hand-holding; I need context and candor. Micromanagement would kill me, but so would being left without any strategic direction.
As a founder wearing many hats, how did you decide where to spend your own time?
I asked what only I could do, and tried to spend my hours there — usually the hardest product calls and the key relationships. Everything else I delegated even when I could do it better myself, because a founder who does everything becomes the bottleneck.
How did you handle two urgent priorities pulling at you at once?
I forced myself to name which one, if ignored, actually threatened the company, and did that first. Both feeling urgent is usually an illusion. I'd rather do one thing well and let the other slip a day than do both badly and drop the one that mattered.
Tell me about pushing back on a board member or investor.
One board member wanted us to chase a big enterprise client that would've distorted the whole product. I pushed back that serving them well would break our model for everyone else. I brought the numbers, not just conviction. Saying no to revenue is one of the hardest founder muscles.
Did you ever have to let someone go? How did you handle it?
Yes, and I did it too late the first time out of loyalty, which hurt the team. I learned to act sooner and to do it with dignity — clear reasons, real support to land elsewhere. Keeping the wrong person is unkind to everyone else carrying them.
How did you cope with the stress and eventual failure personally?
Not perfectly — I tied too much of my identity to the company and the shutdown gutted me. What helped was separating 'the company failed' from 'I am a failure'. I built something real that reached forty thousand people; the venture died, but the capability didn't.
Tell me about a process you built that outlasted your own involvement.
The weekly metrics review the whole company ran on — I designed it so anyone could see what was working without me in the room. My mistake was the wrong headline metric, but the ritual itself was good enough that the team kept running it even as I stepped back.
What do people misunderstand about you?
That because I ran a startup that failed, I must be reckless. Actually the failure taught me the opposite — I'm now almost annoyingly disciplined about viability. People expect a wild-eyed founder and get someone who wants to see the unit economics before falling in love with anything.
Is there a value you won't compromise on?
Honesty with the people who trust you — team, users, investors. Near the end there was pressure to overstate our health to raise more. I wouldn't inflate the story. If the truth couldn't save it, a lie certainly shouldn't. My credibility outlives any one company.
What does great collaboration feel like to you?
When I bring a team the problem and they hand back something better than I imagined. The USSD flow my engineers designed still stands out — I gave context, they gave brilliance. Great collaboration is when owning the 'why' lets other people own a 'how' beyond you.
What skill are you deliberately building for a PM role specifically?
Working within a bigger system's constraints. As a founder I had total authority; a PM has to influence and align across a machine I don't control. I'm learning to drive outcomes through persuasion and process, not just decree, because that's the muscle I never had to build.
Finally, if you joined a product team and it went well over two years, what would success look like?
I'd own a product area where the roadmap ties clearly to outcomes, where we killed as many things as we shipped, and where the team trusts my no's. And I'd have brought the founder's discipline — viability first, users always — without the founder's blind spots.