B2B heavy-equipment marketplace
What it is
A rebuild of a heavy-equipment marketplace into a procurement platform for corporate buyers.
Who it's for
Corporate buyers who purchase through internal approval, and the heavy-equipment merchants who sell to them.
How it works
Eight workstreams under one plan, from simplified listing and registration to payment options, merchant reporting and a mobile inspector tool.
The problem
Context
A marketplace connecting heavy-equipment merchants with corporate buyers had grown on a standard e-commerce model. Corporate procurement doesn't work like a shopping cart.
Client name withheld under NDA. Details below are generalised.
What we learned first
Four problems sat under 'the site feels old': a checkout that doesn't fit approval-based buying, a single payment method, three confusing registration paths, and merchants with no view of their own performance.
Constraints
- Fixed effort budget (man-days) agreed before discovery finished
- End-of-life framework version had to be upgraded alongside new features
- Small team: one engineer across backend, web, CMS and mobile
My role
Richard on this project
Product & Project Manager, QA
Product skills
- PRD writing
- Scope adjustment
- Procurement flow design
- Process diagrams
Project skills
- Programme management
- Client checkpoints
- Jira
- End-to-end QA
As product manager
- Wrote the PRD and the scope-adjustment brief
- Reframed a shop flow into a procurement flow
- Drew the payment-flow and process diagrams
As project manager
- Ran a 9-month programme across 5 phases, discovery to UAT
- Held weekly checkpoints with the client and tracked all 8 workstreams in Jira
- Ran end-to-end QA on staging and consolidated the reports
Not my role
- Commercial proposal and pricing: handled by Summon leadership
The work
Key decisions & trade-offs
- Decision 01
Reset scope after the PRD, in writing
Once the PRD was detailed, several requests clearly exceeded the agreed effort or fell outside the role we were engaged for. I wrote a scope-adjustment brief (internal and client versions) that listed each item, its effort, and the options.
Trade-off An uncomfortable conversation early, so the deadline holds later.
- Decision 02
Test full buyer journeys
QA followed full journeys (register โ list โ transact โ pay โ report) against the PRD, separating what was genuinely new from what already existed, so the client saw progress as journeys that worked.
Trade-off Takes longer than ticket-by-ticket checks, but it reflects how the client will actually use the product.
How it was built
Eight workstreams: simplified listing, registration, transaction and payment options, feature adjustments, merchant reporting, a framework upgrade, and a mobile inspector tool, delivered in five phases from discovery to UAT.
- Item โ requested behaviour โ effort impact โ recommendation
- In scope as agreed / Adjusted (smaller version now) / Deferred to next phase
The result
- 8
- workstreams under one plan
- 5
- delivery phases, discovery to UAT
What I'd do differently
I'd push for the scope conversation before the effort estimate is signed. The brief worked, it just arrived later than it should have.