A few short weeks ago, my colleague Graeme Ogle posted his thoughts on five essential characteristics of a great product owner. Graeme’s list is made on the back of his experiences and those of product owners he has worked with.
I thought I would riff a little on a related theme, hence this list of skills or behaviours that make agritech product teams effective. Some of my ideas here are based on software development projects I’ve been involved with over the last 30 years, and others stem from my recent experience as (part time) product owner for our Pure Farming platform over the last 15 months.
1. Great teams align with product goals – and try to exceed them
Our product teams perform best when we openly share, discuss, and understand the product goals, not just the tasks or features. I’m not sure the days ever really existed when we wrote product requirements in isolation from the developers, and slid instructions under the door along with a pizza.
When the product manager or owner spends time with the team, helping them to understand how they want the product to benefit their business, and for farmers or other agricultural sector users to benefit, the team can suggest ideas and prioritise work to achieve those outcomes.
Importantly, when time constrained (as every project is), the team can recommend how we could implement features or prioritise pieces of functionality to achieve the overall outcome, even if some of the ideas on my wish-list might be delayed.
2. Effective teams build deep subject matter understanding
I’m sure it’s possible to build an agricultural product with a team that doesn’t understand agriculture. However, when our teams create products for farmers and field teams, and do it again and again, they build an understanding of the context, capability and needs of those users. Some of our user experience teams are expert at this, and frequently challenge me with what they have learned from previous projects about farmer needs and preferences.
I’m also always encouraged when a developer or business analysis takes it upon themselves to read documents and papers related to the subject matter – whether they are researching how slope and aspect affect pasture growth; or asking me whether I have captured all the edge cases around livestock treatments.
3. They are pragmatic about build vs. buy
Tackling the many technical challenges between concept and finished agritech product is what really interests most development teams. A secret to cost-effective and rapid development, lies in knowing when you need to solve a problem from the ground up, and when to build on the work of others.
In one customer project recently, our team implemented BigCommerce in “headless” mode to provide e-commerce capabilities for a web site. The customer got their custom user experience, and our team avoided building e-commerce functionality that exists elsewhere. In another case, a customer was able to use our Pure Farming platform to manage user authentication and farm data access, without needing to build this functionality themselves.
The trade-offs between the exact “fit” of a totally custom solution, and the imperfect but satisfactory fit of a commercial or open-source component are not always obvious. When I’m acting as product owner, I appreciate the ideas, questions, robust debate of our technical leads about these choices.
4. Long-lasting teams balance pace and sustainability
Markets don’t stand still when you’re trying to develop a new or improved agritech product. One of the key elements of success is the ability to shorten time to market, or better still, to be able to rapidly iterate and learn over multiple cycles.
This can lead towards a massive emphasis on pace of delivery, with speed trumping all else. But should it? I’ve led software teams where we have all worked huge hours leading up to a product release, including all-nighters to shake out and fix the last bugs or performance issues. These heroics are sometimes necessary (especially in agriculture where seasonal activities are often more fixed than demos or marketing launches), but they are not sustainable over the longer term.
When I am a product owner, or with other product owners, I now encourage them to consider product development as a series of short, incremental learning cycles rather than one major release. This gives us time to get feedback and adjust the product.
In this context however, a super-fast pace or heroic long hours before a launch may not help us. In fact, unsustainable pace and overcommitted schedules may cause our team to make errors, miss key insights, and ultimately burn out. Our teams and product owners are learning to find the productive middle ground: ways to shorten the learning cycle with frequent small releases and yet keep work commitments for the team within sustainable limits. We don’t always get this right, but it’s important and we are making progress.
5. Effective teams don’t just start coding
When a new product development kicks off, or a new feature is begun, it’s tempting to want to make lots of progress, and have the team start coding straight away. This is particularly tempting when, like Rezare Systems, you undertake custom software development for your agritech customers. Time is money (for both parties), right?
Well, maybe not.
It’s easy for development teams to jump into coding using the tools, architecture, and services they used in the last project. Equally, it’s exciting and interesting to instead choose the hot development stack and architectural pattern of the day. Whether it is CQRS, DDD, Strangler Pattern or Microservices or SQL vs. document databases, they can all be justified and sound great at the outset.
I’ve really appreciated it when trusted members of our team – our solution architect and senior developers (and those of our customers) spend time in consideration and discussion, weighing the real performance needs and design considerations before we decide how products will be built. This thinking time can be invaluable.
We use Amazon Web Services to host our Pure Farming platform and many of our customer projects. I’ve been very grateful for the interactions between our technical leads and the AWS solution architects as they discuss the strengths, weaknesses, and hosting implications of different services and architectures.
The bottom line
If you are a product owner or product manager, or considering developing an agricultural software product or service, play to the strengths of your development team. Make sure that they are involved early in the design decisions. Empower them with a deep understanding of your field of use and your product goals. Remember the trade-offs between delivery speed, sustainability, and good decision making.
Wishing you all the best with your product development project!
Feedback, ideas? Let us know below: