Ruminate connects food producers with the evaluators who decide whether a product is ready for market. I led discovery and strategy for the two-sided platform, mapping how each side moves from sign-up to a completed transaction and identifying the friction points most likely to block a paid evaluation.
Ruminate is a two-sided platform where producers pay to receive structured feedback from evaluators who help shape whether products reach shelves. I translated discovery research into end-to-end journeys for both sides, then identified the friction points most likely to stall the marketplace before a paid evaluation could happen. The core strategic call: prioritize the producer's path from sign-up to approval, checkout, matching, and a completed evaluation before expanding into secondary features.
Ruminate has two heroes. The producer is a food maker who needs honest, expert feedback before risking a launch. The evaluator is a domain expert (retailer, distributor, or specialist) who wants meaningful work reviewing products in their wheelhouse. The platform dies the moment either side hits a dead end.
The flows were genuinely complex (sign-up, approval, pricing, checkout, matching, evaluation) and the client's needs kept evolving. Strategy had to stay decisive without becoming rigid.
Studied both sides of the marketplace to validate needs and find where producer and evaluator incentives align or conflict.
Mapped both personas end to end. Producer: landing, sign up as producer, application approval by Ruminate, pricing package, checkout, dashboard, start and complete evaluations, product intake form. Evaluator: Google login with permissions, profile, approval, dashboard, review the product intake form, submit feedback, and update progress.
Ranked the build by where the journey was most likely to stall, tying each decision to the producer's path to a paid evaluation.
Approval gating, pricing and checkout, and matching all had to be airtight before any nice-to-have feature.
Both producers and evaluators are vetted and approved by Ruminate. This protects evaluation quality but adds friction, so the flows had to handle pending states, email notifications, and limited-versus-full dashboard access gracefully.
Google login with permissions reduced friction on the supply side, where signup drop-off is most costly.
The user flow was treated as a living document, scoped explicitly per phase so engineering always knew what was in and what was out. Phase 4 centered on the producer dashboard path. Secondary features (FAQ, notifications, messaging, waitlist) were deliberately deferred, and earlier Phase 3 flows were revised based on direct client feedback rather than carried forward unchanged.
Where the two sides conflicted, I prioritized the constraint that blocked the core transaction: a producer being able to pay for and receive a matched evaluation.
This was strategy and planning work, so the outcomes here are a buildable plan and an aligned team; post-launch metrics don't exist yet. To make the critical path measurable at launch, I defined the funnel metrics worth instrumenting: signup completion by side, drop-off at approval, time-to-first-match, and the share of producers who reach a paid evaluation. Whether the marketplace succeeds depends on execution and live-market validation that is still ahead.
Clear producer and evaluator user flows aligned the cross-functional team on a shared model.
Non-essential features were deferred so the team stayed on the producer's path from sign-up to a paid evaluation.
Explicit per-phase scope gave the client and engineering a shared, stable definition of done for each phase.
The strategy rests on a bet that discovery supported and live transactions haven't tested yet: that producers will pay for matched evaluations. The real test is launch, and that is still ahead.
Focusing on the producer path first was deliberate, but it means evaluator-side friction and the classic cold-start supply problem remain open.
The client's requirements kept evolving. A living user flow and tight phase scoping reduced thrash, but some calls were bets made with incomplete information.
I would run a concierge experiment before the full build, manually matching the first producer-evaluator transactions, to get behavioral evidence on the paid-evaluation assumption rather than waiting for launch to learn whether producers will pay.
In a two-sided platform, strategy is mostly about sequence: you cannot optimize one side in isolation, and you cannot build everything at once. Naming the single path that has to work first, and protecting it from scope creep, did more for the product than any individual feature.
And when requirements keep shifting, a living user flow plus tight phase scoping is what keeps a team moving without thrashing.
