“Businesspeople and developers must work together daily throughout the project.” Agile Manifesto, Principle #4
The authors of the Agile Manifesto had seen too many development efforts languish because developers couldn’t get enough time with their counterparts in business to make good decisions. They set out to change that.
The Agile Software methods that spun out of the Agile Manifesto have dedicated roles for business people, typically called “Product Owners.” The Product Owners are the ones who participate and give feedback in the demos, and then prioritize the work in the backlog to help the team decide what to work on next. The Product Owners are also supposed to be interacting with the team on a daily basis in between these events, to provide real-time feedback and answer questions.
Every Product Needs a Product Owner
I’ve worked on a lot of products and most of them have had someone — usually, but not always, from Marketing — who is responsible for providing feedback and answering questions about the customer and market needs. I’ve also worked with a lot of teams where this function was weak or nonexistent, and it showed. The teams struggled in predictable ways to gather and interpret customer input.
We made the conscious decision with Rapid Learning Cycles to avoid defining numerous roles — physical product teams vary too much for that kind of standardization. But it is a big red flag for me if ONLY the technical team is using Rapid Learning Cycles, or if Marketing has dropped a requirements document on the group and then doesn’t show up for meetings after that. Most teams have a lot to learn about customers, some of which only can be learned after a customer has something to elicit a reaction.
We also learned, early on, that teams needed a strong sense of direction about the customer and the business, even if the final destination was still subject to change. For a development effort to be funded, there must be at least some idea about who the customer is, why they care about the product, and what the company will get from delivering it.
Every Product Has a Core Hypothesis
The Core Hypothesis, the first element of Rapid Learning Cycles, is the reason why the company is developing a product, technology or new business idea. To build it, the team writes the technology to be used, with the customer and business value that the product will deliver. If the Marketing / Product Owner function is weak, the team will struggle and argue about the customer and business value, and then struggle to validate their assumptions.
The process of writing the Core Hypothesis strengthens the team’s understanding and builds alignment in every case. When they struggle with customer and business value, that’s a signal that the team needs better representation from the business and stronger objectives around the value that the product is intended to deliver. The team is too disconnected from the customers. But even when things are going well, it’s still important to not completely outsource all customer knowledge to Marketing, Sales or even Industrial Design.
Every Developer Needs Some Customer Contact
The reason why “daily” is in the original Agile Manifesto is that it provided the developers access to a customer or customer proxy who would be able to work side-by-side with them as they mapped out user interfaces or validated algorithms. That naturally leads to a transfer of customer knowledge, so that developers can gain a deeper understanding of the context where their product will be used. For software with a user interface, it doesn’t really matter where this side-by-side work takes place, as long as the devices are available that the customers will use.
That’s not true for a physical product — or for a software product, like an inventory scanning app — that’s designed for a specific place where context matters. The people designing the UX for warehouse management need to spend some time in warehouses — ideally a warehouse where their app will be deployed. The people designing physical products also need to understand the environment that will surround their products in the field, and the best way to do that is to spend some time observing people in the environment.
This helps developers of all kinds make wise decisions about the kinds of things that don’t lend themselves to requirements or even user stories. Without this, we tend to design products for the people we know best, or for ourselves. For example, when I was at HP, we designed our first low-cost printers for light-duty home use only. We assumed that people would install an inkjet cartridge and leave it there until it ran dry.
But we learned that many of these printers ended up in Internet cafes in emerging countries, where they were heavily used — and where ink cartridges were removed at night to keep them from being stolen, both of which caused the printers to fail faster in the field. It’s no surprise that we had a lot of warranty claims and negative reviews from these users, who had user stories we didn’t anticipate. And users are not the only people who can provide useful contextual feedback to consider.
Physical Products Have Other Downstream Partners to Consider
This principle needs just a little modification for physical products, because it’s also not inclusive enough. Hardware developers need to incorporate feedback from downstream partners in production, supply chain and service. At the same time, they may not benefit from daily interactions — most teams making physical products meet once or twice a week, and that’s probably often enough. Which leads to this refinement of the principle:
“Business people, downstream partners and developers must work together frequently throughout the project.”
