Until now, in the Impact Driven Product development cycle, we have arrived at a shared understanding of Key Business Outcomes and feature ideas that can help us to deliver value to our customers and maximize the impact on the KBOs. The next step is for us to identify what success means to us. For the kind of impact that we predict our feature idea to have on the KBOs, how do we ensure that every aspect of our business is aligned to enable that success? We may also need to make technical trade-offs to ensure that all effort on building the product is geared toward creating a satisfying end-to-end product experience.
When individual business functions take trade-off decisions in silo, we could end up creating a broken product experience or improvising the product experience where no improvement is required. For a business to be able to align on trade-offs that may need to be made on technology, it is important to communicate not just what is possible within business constraints but also what is not achievable. It is not necessary for the business to know or understand the specific best practices, coding practices, design patterns, and so on, that product engineering may apply. However, the business needs to know the value or the lack of value realization, of any investment that is made in terms of costs, effort, resources, and so on.
This chapter addresses the following topics:
- The need to have a shared view of what success means for a feature idea
- Defining the right kind of success criteria
- Creating a shared understanding of technical success criteria
"If you want to go quickly, go alone. If you want to go far, go together. We have to go far — quickly."Al Gore
Planning for success doesn't come naturally to many of us. Come to think of it, our heroes are always the people who averted failure or pulled us out of a crisis. We perceive success as 'not failing,' but when we set clear goals, failures don't seem that important. We can learn a thing or two about planning for success by observing how babies learn to walk. The trigger for walking starts with babies getting attracted to, say, some object or person that catches their fancy. They decide to act on the trigger, focusing their full attention on the goal of reaching what caught their fancy. They stumble, fall, and hurt themselves, but they will keep going after the goal. Their goal is not about walking. Walking is a means to reaching the shiny object or the person calling to them. So, they don't really see walking without falling as a measure of success. Of course, the really smart babies know to wail their way to getting the said shiny thing without lifting a toe.
Somewhere along the way, software development seems to have forgotten about shiny objects, and instead focused on how to walk without falling. In a way, this has led to an obsession with following processes without applying them to the context and writing perfect code, while disdaining and undervaluing supporting business practices. Although technology is a great enabler, it is not the end in itself. When applied in the context of running a business or creating social impact, technology cannot afford to operate as an isolated function. This is not to say that technologists don't care about impact. Of course, we do.
Technologists show a real passion for solving customer problems. They want their code to change lives, create impact, and add value. However, many technologists underestimate the importance of supporting business functions in delivering value. I have come across many developers who don't appreciate the value of marketing, sales, or support. In many cases, like the developer who spent a year perfecting his code without acquiring a single customer (refer to Chapter 2, Invest in Key Business Outcomes), they believe that beautiful code that solves the right problem is enough to make a business succeed. Nothing can be further from the truth.
Most of this type of thinking is the result of treating technology as an isolated function. There is a significant gap that exists between nontechnical folks and software engineers. On the one hand, nontechnical folks don't understand the possibilities, costs, and limitations of software technology. On the other hand, technologists don't value the need for supporting functions and communicate very little about the possibilities and limitations of technology. This expectation mismatch often leads to unrealistic goals and a widening gap between technology teams and the supporting functions. The result of this widening gap is often cracks opening in the end-to-end product experience for the customer, thereby resulting in a loss of business. Bridging this gap of expectation mismatch requires that technical teams and business functions communicate in the same language, but first they must communicate.
In order to set the right expectations for outcomes, we need the collective wisdom of the entire team. We need to define and agree upon what success means for each feature and to each business function. This will enable teams to set up the entire product experience for success. Setting specific, measurable, achievable, realistic, and time-bound (SMART) metrics can resolve this.
We cannot decouple our success criteria from the impact scores we arrived at earlier. So, let's refer back to the following table that we derived in Chapter 3, Identify the Solution and its Impact on Key Business Outcomes, for the ArtGalore digital art gallery:
The estimated impact rating was an indication of how much impact the business expected a feature idea to have on the Key Business Outcomes. If you recall, we rated this on a scale of 0 to 10. When the estimated impact of a Key Business Outcomes is less than five, then the success criteria for that feature is likely to be less ambitious. For example, the estimated impact of "existing buyers can enter a lucky draw to meet an artist of the month" toward generating revenue is zero. What this means is that we don't expect this feature idea to bring in any revenue for us or put in another way, revenue is not the measure of success for this feature idea. If any success criteria for generating revenue does come up for this feature idea, then there is a clear mismatch in terms of how we have prioritized the feature itself.
For any feature idea with an estimated impact of five or above, we need to get very specific about how to define and measure success. For instance, the feature idea "existing buyers can enter a lucky draw to meet an artist of the month" has an estimated impact rating of six towards engagement. This means that we expect an increase in engagement as a measure of success for this feature idea. Then, we need to define what "increase in engagement" means. My idea of "increase in engagement" can be very different from your idea of "increase in engagement." This is where being S.M.A.R.T. about our definition of success can be useful.
Success metrics are akin to user story acceptance criteria. Acceptance criteria define what conditions must be fulfilled by the software in order for us to sign off on the success of the user story. Acceptance criteria usually revolve around use cases and acceptable functional flows. Similarly, success criteria for feature ideas must define what indicators can tell us that the feature is delivering the expected impact on the KBO. Acceptance criteria also sometimes deal with NFRs (nonfunctional requirements). NFRs include performance, security, and reliability.
In many instances, nonfunctional requirements are treated as independent user stories. I also have seen many teams struggle with expressing the need for nonfunctional requirements from a customer's perspective. In the early days of writing user stories, the tendency for myself and most of my colleagues was to write NFRs from a system/application point of view. We would say, "this report must load in 20 seconds," or "in the event of a network failure, partial data must not be saved." These functional specifications didn't tell us how/why they were important for an end user. Writing user stories forces us to think about the user's perspective. For example, in my team we used to have interesting conversations about why a report needed to load within 20 seconds. This compelled us to think about how the user interacted with our software.
Some years ago, a friend of mine, who was working as part of a remote delivery team with little access to the real end users, narrated an interesting finding. Her team had been given a mandate to optimize report performance. One of her team members got an opportunity to travel to the location of some customers and observed how they used their software. The prime functionality of their software was to generate reports. The users would walk in at the beginning of the day, switch on their computers, launch the software, initiate a report, and step out for their morning coffee. The software took a good 15 minutes to generate a report! By the time the users had their coffee and had come back, the reports were ready. The customers had changed their habits to suit the software! The real question was how were we to react to this finding? Should we fix the reports to run faster? Should we leave them as is and focus on building other valuable functionality for the customers? Should this be a decision that technology must make in isolation?
It is not uncommon for visionary founders to throw out very ambitious goals for success. Having ambitious goals can have a positive impact in motivating teams to outperform. However, throwing lofty targets around, without having a plan for success, can be counter-productive. For instance, it's rather ambitious to say, "Our newsletter must be the first to publish artworks by all the popular artists in the country," or that "Our newsletter must become the benchmark for art curation." These are really inspiring words, but can mean nothing if we don't have a plan to get there.
I've heard many eager founders tell product engineers that their product should work like Facebook or Twitter or be as intuitive as Google. This expectation is there from the first version of the product! What do we do when the first release of a product is benchmarked against a product that took 10 years in the making and is a million iterations in? This is what I meant earlier when I mentioned expectation mismatch. It is important to get nontechnical stakeholders on board to meet the ambitious goals they prescribe to their teams. For instance, one of the things I do in ideation workshops is to not discount an ambitious (and impossible) goal such as the one stated earlier. I write it up as an outcome to achieve, and press for stakeholders to lay out their plans for how they intend to support making this happen. For example, at the level of responsiveness, performance, intuitiveness, and feature richness they expect from the product in its first release, we would need a sufficiently large user base and source of revenue to justify the costs/effort that go into building it. What is the business team's plan to source revenue in time for the first release? How do they plan to get the user base again in time for the first release?
Even when a product's technology is its main differentiator, other supporting business functions need to also come together in order to amplify the effectiveness of the technology. Successful products are a result of a lot of small things that come together to create impact.
The general rule of thumb for this part of product experience planning is that when we aim for an ambitious goal, we also sign up to making it happen. Defining success must be a collaborative exercise carried out by all stakeholders. This is the playing field for deciding where we can stretch our goals, and for everyone to agree on what we're signing up to, in order to set the product experience up for success.