Recently, I had the opportunity to work with a passionate team that was building an exciting internal product. For the broader organization, the product played a crucial role in achieving its goals. It could unlock new ways for teams to organize and deliver software. However, when I joined the team, a significant knowledge gap became apparent, the customer.
Being grounded in the needs and interests of customers is not only the foundation of design thinking but also a core tenet or "ideal" of modern DevOps. Customer focus is one of the 5 Ideals of DevOps described by Gene Kim. It provides context, and helps to define the purpose of the work at hand. It ensures the team is solving the right problems, with the right outputs to achieve the desired outcomes. An understanding of the customer’s needs must be understood to do this successfully.
Without a focus on customers, this team was disconnected from their purpose and the product’s value proposition. They were more focused on completing tickets and less on understanding the needs of the customers or the value they added.
In my experience, it's not uncommon for organizations to prioritize the needs of their business over the needs of their customers. And this lack of customer focus contributes to several undesirable outcomes, including four I observed within my new team.
Creating A False Sense of Productivity
With the focus on output, productivity equated to the number of completed tickets. The prevailing notion was that one must always have one or more tickets with their name on them. If the team could not move a ticket forward, folks would start a new one. We were good at starting work but not so great at finishing it.
With a customer-centric focus, productivity is measured by the value it adds to the user, not tickets completed; so the team would prioritize removing blockers over starting additional work.
Discarding Customer Feedback
We often worked without the benefit of feedback, and when we did receive it, we frequently discarded it. When users engaged the product in unexpected ways, we tended to blame the users for misuse instead of empathizing with our customers and understanding what led them to use the product in such a way.
With a customer-centric focus, feedback and empathy are essential to understanding how to continue delivering value and iterate toward desired experiences that delight and engage.
Potential Value Added vs. Actual Value Added
This output-centric focus also impacted our definition of “done.” We were done when we finished all the stories; but without a mechanism for feedback and measurement, there was no way of knowing if those stories contained solutions to the right problems, or satisfied the customers' needs.
With a customer-centric focus, we’re done when we’ve delivered the right experience and enabled users to achieve their goals.
Creating Poor User Experiences
New versions of the product usually proved burdensome for customers to adopt. After a certain point, customers started avoiding new releases until something forced them to update. They learned that upgrading to new versions was a waste of time and best avoided at all costs.
With a customer-centric focus, updates should reduce friction and make adoption easy. Testing versions of the product with customers is part of the iterative design and prototyping practices, helping to ensure each release is a product-market fit.
Shifting From Business-Centric to Customer-Centric
The heart of the problem was the team’s orientation — a business-centric focus versus a customer-centric focus. A business-centric focus centers around completing tickets in a backlog. A customer-centric approach is based upon understanding customers’ goals and creating solutions that enable them to be achieved. It suggests focusing on the value added, soliciting feedback, and establishing measurements to guide progress toward outcomes oriented around the customer — which should then result in positive business outcomes.
These business-centric practices stem from various organizational pressures and incentives, and addressing them often feels like using a tugboat to turn around a cruise ship. Below, I outline a series of hypotheses I proposed to shift the team from a business focus to a customer focus, and the insights I gained from each of them.
Changing the Conversation
Hypothesis: Engaging and empathizing with our customers will help shift the team from being output-focused toward being customer-focused.
We lacked empathy and an understanding of what and when to build for our users. We had gaps in how we engaged with our customers, and we didn’t clearly understand how our work brought them value.
We started by engaging with our customers more often. We held regular check-ins with teams, conducted user surveys, posted updates, interacted more with folks in public Slack channels, and sent out newsletters on our progress. We cast a wider net than we previously had, and started building relationships with folks using our product.
Then we began using user stories in our planning. This tool helped us draw on our relationships to articulate who would benefit from our work and why it added value for them.
Only a few months into the change, we began to frame the product in terms of value added to our users instead of focusing solely on the amount of work completed. Some fundamental changes in the team composition helped bring this about, including a new hire who emphasized the importance of community.
Altogether, the method had a tangible positive impact on the quality of our work.
The takeaways:
- Soliciting new ideas can be effective in changing the conversation but won’t spur action by itself.
- Small changes in team composition can significantly impact shifting the paradigm.
- “Community” is a powerful word that energized. It connected to open source, which team members aspired to participate in.
Adopting OKRs
Hypothesis: Setting objectives and key results (OKRs) will assist in shifting the team away from an output focus toward a customer focus.
This organization had recently started using the OKR framework for goal setting. We tried strategically using team-level OKRs to shift from an output-focused system to a customer-focused one.
When the OKR had a user-centered outcome, we had more success in completing our objective. We noticed a change in behavior and a shift in focus to the customer over completing a predefined scope of work.
Here’s an example of a user-centered OKR:
- Objective: Improve our user experience
-
Key Results:
- Reduce processing time for users by x%.
- Increase the number of user transactions to x per day.
- Capture a baseline net promoter score.
The OKR forced us to collect feedback, accurately measure our progress, and reconnect to our primary goal to ensure we were on the right track. It enabled us to look at the backlog as a function of our intended outcome versus a measure of success. This process led to the team shedding some of the work they had planned to do because they had already successfully met the objective.
On the other hand, we found that OKRs oriented around output reinforced the old output-focused workflow instead of moving us toward customer focus. Below is an example of an output-oriented objective:
- Objective: Create a new way to sign up for the app.
- Key Result: Complete by the end of the quarter.
Some of our team's objectives were quite ambitious, and when it became clear we wouldn’t meet them, the shortcomings weighed on team members.
The takeaways:
- OKRs can be a powerful tool for improving customer focus when oriented around customer outcomes.
- The wrong incentives promote business as usual instead of driving meaningful change.
Defining Outcomes
Hypothesis: Defining outcomes to achieve instead of outputs to complete will lead to customer focus.
Historically, one person on the team was responsible for defining our work. This work came in the form of a queue of stories or tasks.
As the team evolved, we had a noticeable depth of collective experience. For more experienced folks, merely working off a backlog felt less than engaging. We questioned whether setting up scenarios where we defined outcomes instead of outputs would lead to more customer focus. Suppose we used customer-focused project charters instead of a predefined backlog to achieve an engaging outcome. Could we leave the details, experimentation, and delivery for individuals to own?
The results were a mixed bag. One workstream had a clear and measurable outcome, which team members found engaging. The outcomes and results we were aiming for were customer-focused, and this effort led to more engagement with customers as well.
On the other hand, another concurrent workstream with a clear and measurable outcome was underway. The individuals involved in that effort didn’t have the same sense of ownership over the execution and delivery. In the output-centric mode, we gravitated toward silos, and that mindset had carried over here. These folks delivered potential value, stopping short of delivering actual value to our customers because they felt it was someone else’s job to take potential value and convert to actual value.
The takeaways:
- The interest level in this workstyle varies depending on the individual and experience level.
- It also depends on the team’s composition and who would be involved. It is most likely to succeed with folks who thrive in an autonomous environment.
So What's the Point?
We spend so much time, money, and energy building software. It’d be a shame to waste those resources on a solution that solves the wrong problem, or worse, creates more problems. Keeping our focus on the customer (the why) ensures we’re putting energy into building the right experience.
When you find yourself on a product team and discover that you are leading with the needs and interests of the business instead of the customer, attempting to “right the ship” can seem overwhelming. Discovering the right solution can be difficult and requires us to go beyond the backlog and work more directly with users. By starting with small experiments, teams can find ways to shift their focus onto what's most important.