The client
A seed-stage agritech startup offering a B2B SaaS platform that turns barn-level data into actionable intelligence for livestock operations. The platform connects to on-farm sensors and existing hardware to monitor conditions such as temperature, humidity, air quality, feed and water intake, and individual animal activity. It turns these signals into real-time dashboards, trend analyses and automated alerts, helping farmers and herd managers detect problems early, from heat stress to equipment failures, protect animal welfare and reduce losses.
The product was already live with paying farms, sold as a modular subscription priced per barn or per animal, for dairy and beef cattle, swine and poultry operations. The team counted nine people: two backend and three frontend developers, two in sales and two in marketing. With customers, sales and investors all asking for different things, and no one whose role was to weigh those requests against a product goal, every request looked reasonable.
The challenge
- The team was building a lot, but without a clear priority.
- The backlog was growing faster than the impact the product generated.
- Every request from customers, the team and investors seemed urgent, and none was truly discarded.
- The team needed a shared way to decide what to do and, especially, what not to do.
Diagnosis
The problem was the absence of explicit decision criteria. Without a shared filter, the backlog acted as an archive of every idea rather than a tool for making choices.
Requests reached the team from customers, sales and investors, through different channels and with no common way to weigh them. Each was judged on its own, so priority tended to follow whoever asked last or asked loudest. Developers could receive conflicting requests from several people at once, and the plan changed with every conversation.
The clearest example came from the top. The CEO decided to rethink the growth flywheel and redesign the landing pages, pulling frontend and marketing into the work while the roadmap and the prioritisation process were set aside. It was not a bad idea in itself, but with no shared criteria there was no way to compare it with the work already planned, or to ask what it would displace.
The work itself was hard to compare. A new sensor integration, a new alert type, a dashboard improvement and a website redesign competed for the same capacity, with no shared unit to tell which one mattered more. The backlog contained around 200 open items and the team was pursuing eleven initiatives at once. Many requests lacked an explicit product goal or enough evidence to discuss their priority. The cost of not deciding showed up as constant context switching, initiatives left half-finished and a backlog that grew faster than the product’s impact.
Strategic approach
I worked by subtraction, starting with decisions rather than features.
- Redefine decision criteria: work with the team on shared criteria for user impact, contribution to business goals, evidence and effort, applied to every request, whoever it came from, including leadership.
- Clarify what to measure and what to ignore: identify the few metrics tied to product goals, setting aside indicators that did not help the decision.
- Systematically remove low-impact initiatives: review the backlog item by item, explicitly cancelling or postponing requests that did not meet the criteria.
- Establish a steady decision rhythm: recurring reviews of new requests and priorities, with documented reasons for the decisions made.
Delivery
Six weeks of work, with weekly backlog reviews and the evaluation criteria built directly into Jira, so every request was assessed where the team already worked and the reasoning stayed attached to the ticket. The score informed the discussion without acting as an automatic verdict. Metrics: farms with sensors connected and sending data in the first weeks, alerts acknowledged and acted on, and repeat use of core dashboards.
Results
- Backlog cut from around 200 items to a curated 50: the cap was deliberate. Anything beyond it had to earn its place or leave, so the backlog became a tool for choosing rather than an archive.
- Five priorities under discussion at any time: a short, visible list of candidates, evaluated against the shared criteria before entering a sprint.
- One to three priorities in work per sprint: from eleven parallel initiatives to a number matched to the weekly sprint capacity, with the focus on shipping fast every week and growing the product incrementally.
- Same meetings, better decisions: the number of priority calls did not change, but deciding what to work on became easier, and the team left each call aligned on why.
What the client said
“The meetings are the same, but now we decide faster and everyone knows why. We finally have a reasoned way to say no.”
CTO, seed-stage agritech startup