How to Deliver Value as a Surrogate Product Owner

At Facet, we take on other people’s products and treat them as our own. You can call us a surrogate product owner if you’d like, but the wares we sell aren’t so important as the methods we use. From the name of our service, you can probably tell it is somewhat of a “loaded" offering: Product Owner as a Service (POaaS). Product owners do a lot to steer and drive their development team and their entire organization toward one cohesive product solution. You might think: how can you possibly move the needle for companies better than in-house product owners?

The short answer: we don’t.

We work well with organizations who:

  • Don’t quite know what they want,
  • Have marketing, design, etc teams and need someone to translate it into a technically-feasible vision,
  • Need help translating the hieroglyphics on their requirements document into modern day literature, or
  • Need a shepherd to guide them through scrum practices that deliver value to customers and stakeholders.

 

One kind of shepherd. via GIPHY

 

Our process is simple, and I’ll summarize it in 3 points

  1. Value
  2. Mapping
  3. Testing

Value

We focus on value-driven development in all of our engagements. Whether we are in an ongoing product owner role, or are simply performing the initial solutions architecture to validate a project during a discovery workshop, it is all about delivering value. Capturing “what is valuable to the customer?” is often difficult. How do you create a hierarchy of priorities across an often complex and multivariable user experience?

To start: challenge every request.

We often find customers don’t know what they want, they just know what they want to accomplish. We’ve learned to take features out of the conversation and instead focus on goals.

 
Focusing on goals for the business

We slice value-driven development two ways. One is value delivered to the user, and the other is  value delivered to the business. We can’t qualify the value of a feature if we don’t understand which key metrics are important to the success of the project.

Positive value factors may include:

  • increase in engagement with customers
  • X% growth in revenue
  • reduction by Y% costs for administration
  • etc.

Negative value factors may include:

  • Internal organization politics
  • technical debt
  • budget constraints
  • and more.

The idea here is no matter which feature you build—you must tie each feature to a key goal for the business. Building a foundation based on business goals allows us to have meaningful conversations around features—and pare down ideas to the most effective versions for the business.

 
Focusing on goals for the user

Once we’ve identified business goals, we’re ready to have a conversation around what value we’re delivering to end users. As we have discussions around the value delivered to the end user, we don’t try to quantify the value. Instead, we create hypotheses around which features create value, and test those hypotheses by identifying which KPIs will give us the most insights against our business goals.

In order to have an appropriate conversation around the value delivered to the end user, we must first build a map to illustrate the user journey.

Mapping

Facet leverages story mapping as much as possible to build visual maps. These maps convey clear priorities, illustrate a complete picture of a single user’s journey, and are easily expanded, sliced, and shipped. The key here is collaboration, and the story maps provide a common visual understanding of the steps involved in each user journey.

Before we’re able to discuss the user journey on a website from a functional standpoint, we first define the buyer through their buying phases, their motivators at each buying phase, and the potential touch points we might have with them when they engage with our product. We call this technique persona story mapping.

 

Persona Story Map

Now that's a map.

 

Persona Story Mapping

Persona story mapping is Facet’s adaptation of the user story mapping technique popularized by Jeff Patton—mixed with some common thought exercises one might use while defining a buyer persona. We tend to dislike the rigidity of buyer persona cards, so over time we grew into using the story mapping style to work with our partners on defining:

  • who their buyers are?
  • what the buyers are thinking about in each phase of the buying process?
  • what decision-making factors influence them in each stage?
  • what touch points do we have with buyers?

We use this technique for both our inbound marketing clients and our discovery workshop / product owner as a service clients. It’s important to go through this exercise and define the buyer journey. Even if the end user isn’t really buying anything—they're still buying into the experience.

 
User Story Mapping

I won’t go into user story mapping techniques too much here. There are tons of great resources online, and if you haven’t already, you should definitely read the book.

But—to summarize—user story mapping is a visual storytelling technique used to map out a customer’s journey through a product to complete key actions or goals. Along the top of the story map, we mark:

  • Row 1: Key Goals
  • Row 2: Steps required to complete that goal. These are often verbs.
  • Row 3 through N: Each column contains detailed pieces of functionality, design, infrastructure, technical debt (the list goes on) which need to be addressed in order to execute the verb at the top of the column in Row 2.

 

User Story Map

User Story Map

 

via http://availagility.co.uk/2008/10/28/kanban-flow-and-cadence/user-story-mapping/

Story mapping gives us a common ground to have conversations around the user experience—filling in gaps, and identifying potential risks or road blocks in development.

For anything at which we can’t wave our magic wand of all-knowing power—we set up a test.

Testing

We’re not talking about QA here. When we say testing, we mean the scientific kind.

We have a hypothesis, and we need to build a product experience in order to test it. Any feature or user experience we think is testable or unclear, we mark up with our specific testing criteria and make sure the client understands we have low confidence in designing a perfect user experience outright. With the client on board, we’re able to transform unknowns into valuable learning experiences.

Getting to Launch

Ultimately, I think we’re able to deliver value due in large part to the surrogate leg-work done up front. We uncover the terms of the project via business requirements and business goals, then we learn how to have conversations around user experiences while keeping those business goals in context. It is important to remember the user experience can only be supported so long as the business continues to grow! We do well to serve both our clients and their customers by bringing the right tools and the right people to the table.