Vertical Questions: The “Why”, “What” and “How” of an Effective Digital Product
If you run a business nowadays, you are probably looking at ways that technology can make your business more profitable or less costly. This might mean that you’re considering whether or not to build a new digital product to help achieve one or both of these goals. In this article, we’ll talk about the typical questions you’ll need to answer in order to plan and build an effective digital product.
Verticals
A team centered around developing software generally has three main organizational parts, or “Verticals”: Business, Product and Engineering.
An organizational Vertical is setup like a pyramid, with one or a few leaders at the top, expanding down to the contributors at the base. Verticals operate independently, from a management perspective, but in cooperation with one another. The role of each vertical — in its simplest form — is to answer a specific question.
Why
Business answers the question: “Why?”
The entire process starts (or should start) with this question, and the answer sets the stage for all the other parts to be set into motion by setting the overall goal for an application from a business perspective. This is a very important distinction from the goal of the app from a user perspective. These two goals are linked, but are definitely NOT the same. Treating them as if they are the same is a recipe for a product that no one at your company cares about. Trying to build a product without first answering this question inevitably leads to an aimless development cycle, resulting in a product whose usefulness to its creators can’t be measured, since it has no stated purpose. This is why the Business vertical should always provide a Mission Statement, which clearly outlines the business goals of the products, and defines the criteria that constitute success.
At its core, at a for-profit business, the goal of nearly every application is either to:
- Generate Revenue, OR
- Reduce Cost
However, neither of these on their own can be the answer to the question, because they’re both much too broad. Once the business has identified the family of the goal, more specifics are necessary for Product to take over. The business would need to say something like:
The product should reduce costs by making it easier for customers to manage their accounts without needing to make a phone call for support.
This is an achievable, measurable goal. We can compare the number of users calling support before and after the product launches, as well as collect other data from the product, to draw reasonable conclusions about its effectiveness.
What
Product answers the question “What?” — as in, what are we going to build in order to achieve the Business goal. The Product vertical is responsible for creating a vision of what the product is actually going to be, and what it’s going to do.
This is where the concept of user value comes into play. Before now, we were only considering business value, which is the reason for the product to exist in the first place. But in order for a digital product to achieve anything, it must provide some utility to its users. Sometimes this is simple and obvious — a retail app provides business value by selling stuff, and user value by making it easier for users to buy stuff, or even automate buying stuff through subscriptions. Instances of when the application is able to offer user value that the user uses to generate business value is called a conversion. In the example of our retail app, each time a user makes a purchase is a conversion.
But the user value can be much more complex, and less obviously related to its business value. One currently prevalent means of conversion is advertising. Social media and search companies are built entirely on this model. It works like this: Users are drawn to the app and engaged for a measurable amount of time. During that engagement, in addition to whatever content generates the engagement, the application inserts content that the user isn’t intrinsically interested in: ads. The user usually pays nothing for the app; instead, the advertiser pays the application provider for access to its user-base. Larger user bases and longer engagements yield higher ad costs, so features are generally engineered to maximize them.
How
How? is the central question of the Engineering vertical. Engineering takes the requirements and design from Product and composes application code (and usually remote APIs) to drive the experience. Product Requirements are translated into technical requirements, then into implementation designs, and finally, functional code.
Engineering is generally the last team to the party; normally consulted at last, when everything has been conceived and designed. However, the most successful organizations involve engineers deeply in answering the What? question as well. This is wise, because technical implementations — although possible — may be time consuming or difficult, which is to say, expensive. All application and feature development efforts have a set budget, so involving your engineers in answering the product (and design) question can make the difference between doing things once and delivering on time and on budget, and reworking things that turn out to be too complex, and likely incurring a delay or an overrun.
Roles
One of the most important things for a team to get straight at the beginning of product development is what each person on the team is responsible for. Everyone on the team should know who is tasked with answering each question, and everyone on the team should also know what question they themselves are responsible for answering. This seems like a simple, obvious step in the construction of a development team, but frequently roles are fuzzy, and people are over or under-stepping the boundary between verticals, failing to provide critical answers, or trying to answer the wrong questions. Every team should have a single point of contact for each vertical, called owners. The Business owner is the last word in the goals of the app, the same way the Product owner holds the buck for what the product is. The Engineering (or Development) owner manages the operation of the engineering team, chooses technologies and architectures, and oversees the development effort to ensure that the right things are built the right way to achieve the product and business goals.
Order
There is an ideal order to all things, and for vertical questions, the order is
- Business
- Product
- Engineering
Trying to answer any of the three questions before the previous question has been answered invariably leads to ineffective products that either can’t achieve their goals or worse — have no goals at all. In order for any digital product to succeed, it must have a stated business goal which is understood and accepted by all stakeholders. Without this basic mission statement, no product feature can be measured, or its success quantified.
A product with no business goal is basically a shot in the dark. But there is a process to it that too many teams are forced to employ:
- Build something that’s a repository of often random or loosely related features
- See if somehow it makes money, and identify the source of business value
- Work to reinforce and optimize it.
With deep enough pockets, this can be a valid development strategy, but the risk here is that none of the features generate business value, and the entire project is just an exercise of setting money on fire. To prevent this is simple: make sure you know what you want the app to do before you start building it.
