Menu
close
What really matters when planning and building new product features?
We worked with an ag tech company that was building an app for field staff to monitor the planting progress of partner farmers. The client was so focused on getting the system ready to produce intricate geospatial analyses that the basic requirement of the core user—the field staffer—was forgotten: the app needed to work in a rural, poor network environment. When the app finally shipped, the payload of every single sync job between the server and the app was so large that the app timed out. Despite the best of intentions, the user’s job was harder. The field staff stopped using the app; offline reporting methods were easier than dealing with a poor product experience.
How to get back on track? We started by examining and documenting all the essential jobs-to-be-done. Before spending too much time on downstream analysis and presentation layer, we needed the data collection job to work flawlessly in the customer’s environment. That ensured adoption and usage, which were the necessary precursors to produce the data needed for analysis at scale. We designed and implemented a bullet-proof sync process that would “catch up” in the background once a user emerged from an area without network. Once this basic mechanism was operating smoothly, we moved on to tackle analytics.
Our value to the client:
We achieved clarity on product priorities, starting with the most essential jobs first. As a result, adoption took off and data collection was possible at scale.
What causes product and engineering teams to fall short of their potential?
We worked with an ecommerce company that was struggling with velocity and quality of shipped features. The engineering team had tried to run development sprints but often mid-sprint the team discovered gaps or logical flaws in user stories. Also, frequently new requirements were injected by the leadership team while the developers had already tasked out all elements to get the most out of the sprint. Lastly, the features the team shipped had bugs and performance issues that weren’t caught during QA. All of these issues combined greatly diminished the true output of the technology team and their standing in the organization.
We created objective standards that user stories needed to meet before being appraised by engineering, a scope freeze agreement and reprioritzation framework within product & engineering as well as with the leadership team of the company and a clear definition-of-done including QA and PM sign off.
Our value to the client:
The processes we introduced doubled the output of the technology organization within a three month timeframe.
Why are roadmaps so often unreliable?
We worked with a logistics-as-a-service company that was keen to push into new customer segments. They had many ideas on which features would add value and differentiate their offering. Several teams were assigned to build out the new services and jumped into development mode only to get stuck trying to solve a core architectural component that turned out to be harder to crack than initially assumed.
We helped the company thoroughly screen the foundational technology components that would power their new offering and estimate the level of effort to implement these. We also analyzed the critical path of how these components needed to roll out to use team capacity effectively.
Our value to the client:
The result was a roadmap that the management team could rely on to hire talent and budget expenditure for the coming business year.