Why are relatively few agritech products achieving adoption at scale when billions of dollars are being invested internationally every year? New start-ups appear almost weekly. And established companies are shifting from small innovations around the edges to major projects that sit at the heart of business plans.
Yet for all this activity, few product ideas seemingly “make it”.
We work with many agricultural companies – start-ups and established organisations – to help them develop smart digital products and services. In our experience, there’s a strong correlation between a business’s approach to product management, and their success in developing meaningful products or services that get used. The choice of product manager, the scope and objectives of their role, and their level of skill and authority, drives the success (or otherwise) of the product or service development.
The CEO or a Project Sponsor may define the overall business outcomes and vision, and project managers may be concerned with product budget and timeline, but the product manager is at once the “voice of the product” to the business, and simultaneously translates the “voice of the customer” to the development team (this part of the role is also called product owner). They decide the detailed problems the team will try to solve, the relative priority of those problems, and when the solution is complete enough to be put into the hands of customers.
Here are five tactics an agritech product manager can use to be more effective in their role:
1. Allocate your attention
A product manager juggles many tasks. They must understand scope, be able to prioritise effectively, understand how the team is delivering and what is planned. It’s incredibly hard to do this if the product only gets a small time-slice of your attention.
You won’t be able to effectively manage your product by turning up for a fortnightly sprint planning session. Product managers need to be able to spend time with both stakeholders and the development team. They participate in customer interviews, review the product in showcases put on by the development team, and are deeply involved in product planning workshops.
2. Build stakeholder relationships
New products and services are built at the intersection of customer or user desirability, business viability, and technical feasibility:
- Does this product solve a real problem for its users, and can they readily get the benefits?
- Are customers willing to pay for a solution, and is this solution sufficiently “better” that they will switch?
- Does this product or service meet the objectives and fit the strategic direction of the company?
- Is there a business model that makes sense for the company and which could be profitable?
- Can it be built to operate as envisioned, at a cost the company can justify?
Effective product managers really understand the needs of their users and customers – their behaviours and the problems the product is trying to solve. They use observation and interviews to inform their opinions and seek data from the existing tools or products that customers use.
Product managers must also build trust with the business, effectively communicating how the direction and priorities chosen for the product meet the objectives of the business.
3. Discover, don’t assume
It’s very tempting to build technology products and services the way corporate computer systems were developed in the past: envisage a solution, document it as a set of requirements, and set the development team to work. When the developers and testers are done, roll out the solution (or pass it through to sales and marketing).
Effective product managers know that detailed customer needs are emergent, and so too must be the solution to those needs. They make use of product discovery activities: carrying out interviews, running experiments, and building prototypes. They know that testing an idea by building a prototype and validating that thinking with real users may not only be an order of magnitude quicker and less expensive than building software, it avoids the huge waste of developing robust, performant, tested software that does not address the real problem.
Software and hardware will still need to be built, but continuously using discovery activities to understand and address customer problems reduces the risk of building a great solution to the wrong problems.
4. Prioritise value
If customer and user problems and the solutions are emergent, how can you effectively manage the work of a development team (or teams)? How do you decide what gets released to customers, and when?
Effective product managers decide what discovery and development tasks are the highest priority to work on at any point in time. They pay great attention to the “product backlog” – the set of problems waiting to be worked on, ideas waiting to be tested, and validated ideas waiting to be turned into production software. They may visualise these using story maps, or as items on a Kanban board.
This is not “project management”, seeking to most efficiently have all the tasks completed on time and within budget. Rather, the product manager is making value-based decisions about which tasks or stories (feature sets) are the most valuable to do now, and which can be deferred (and might never be done if sufficient value can be delivered to customers and the business without them).
Product managers consider value on multiple scales:
- Which stories deliver the most value to customers and end users?
- Which stories help the company achieve its objectives (revenue, customer acquisition, or other outcomes)?
- Which activities must be prioritised for the product development process to be successful (for instance, prioritising a discovery or validation activity that may change the overall shape of the product)?
- Which essential dependencies must be built for more valuable stories to work?
5. Release early and often
This may be an agile mantra, but it remains valid. It’s tempting to hold off putting your product into customers hands until it is “complete”. This is especially the case for established companies who worry about reputational risk.
Delaying until the product or service is largely “complete” misses the opportunity to learn how customers choose to use your product or service. They may pay no attention to that wonderful feature you slaved over and be thrilled by other functions. You may discover that the value you expected just isn’t there, and that you need to “pivot” to a different approach. Far better to do this early than wait until the entire budget is spent.
For organisations worried about reputational risk, limited pilots are a useful tool, whether with a subset of staff or a small group of customers. Early adopters may not fully represent your entire eventual market, but carefully chosen they can provide learning and become advocates to your broader market.
Learn More
We use a variety of tools and techniques to support Product Managers in their role, including discovery techniques and activities, dual-track agile (a team working on discovery and a team developing prioritised stories), and flexible scope contracts that focus on value delivery in a time frame rather than a fixed set of requirements.