How do you make a good product?
Part 1: Teams not silos
Digital products have three primary drivers: customer needs, business value, and technical capabilities. If customers have a problem, and you can build a solution to that problem, and that solution makes you money, you have a good product.
I’m a principal product strategist at Endava, a consulting firm that specializes in strategy and software delivery. The nature of our work means our design practice is a little different than agencies. We work mostly with older, larger clients: enterprise companies with decades of technological and physical baggage.
Many enterprise companies know they need to compete in ways unlike the ways to which they’re accustomed. Other players have entered the game and are threatening their whole way of operating (cf. Amazon). These companies often look to outside firms for help. That’s not a bad idea. But the way they engage with these firms often causes its own host of problems.
First they hire a firm to help them with their strategy. They engage with Accenture or McKinsey or the like, who do a good job assessing their client and the market and trends to determine a Course of Action, a General Business Strategy, etc. The consultants help their client to lay out a problem, and then they work very hard to come up with a general solution, and then they collect their money and move on.
Then the enterprise company hires a design firm, an IDEO or Frog or what-have-you to bring clarity to that solution. This design firm makes very nice decks laying out a visual language, and design systems, and prototypes and an obscene number of wireframes. If they’ve really done their homework they have done some usability testing with some of these early prototypes as well.
Then the company hires a development shop like Endava to build it. And the TW team spends some time understanding the problem for which they’re solving and the solution that has been designed. And usually, there are some problems: priorities have changed and the designed solution doesn’t account for those changes, or the solution as designed will cost more than something smaller and simpler in the short- to medium-run.
And when our shop looks for guidance as to the reasoning behind particular elements of the strategy or the design, they often find that pivotal decision makers have left, and there are holes in current knowledge as to why certain choices were made. These chasms of ignorance cause slowdowns or worse, result in the wrong product being built, and highlights the primary problem that this kind of process causes: it focuses on an output instead of an outcome.
Instead of trying to improve the user experience to increase engagement with the company in an effort to build a longer-term relationship with customers, the goal is to build an app. Never mind if that app is something that people will use, or will make money for the business. Getting the app built is the goal. This is not a good goal. The app is a tool. The tool is only a good product if its use profits the business and if people use it.
That’s why we advocate for a cross-functional team of decision-makers at all stages of the process: from visioning all the way to feature creation. This team has representatives from the business, the customers (via design), and engineering. By insisting on this cross-functional team, there is a natural tension that comes from the needs and constraints of each side, that leads to a solid, better product.
