Last week, I kicked off a series on product management principles and lessons I've come to value over time. In part one, the focus was on decision-making, and in this post, I'll focus on how we can execute more effectively once we've made those decisions.
Avoid becoming a feature factory
Businesses aren’t run “left-to-right” and so then it stands the test of reason that product shouldn’t be either. Great product teams focus on how to continuously deliver the most value to the business.
This means not confining yourself to the metaphor of a factory - i.e. delivering a feature and returning to the beginning of the assembly line each sprint.
So, how do you prevent this trap? I believe in changing the concept of “done” and separating it from the agile term “acceptance criteria”.
Done is a construct in which pursuing improvement of a feature, metric, or product is no longer one of the most valuable things the product team could be working on.
This doesn't mean we abandon acceptance criteria. Instead, we may say, "increase conversion by 25% this quarter" and then work on stories that improve conversion until we see that lift. At that point, we re-evaluate if continuing to lift conversion is the best use of our resources.
Forcing functions are mostly good
I define forcing functions as “any device used to create velocity, structure, and reflection”. They are the tools we use to end and begin new feedback loops.
Forcing functions take various forms such as time (sprints), results (metrics), or marginal return. Everyone knows how sprints work, but let's discuss the last two a little more in-depth.
An example results-driven forcing function is the KPI - i.e. "we're going to work on features specifically driving conversion until we hit X%". These are handy for low-hanging fruit or features you know must be improved against industry benchmarks.
Marginal return forcing functions work well on more mature features or products where the return on additional work is too low when compared to the opportunities that can be created elsewhere in the product.
When used correctly, forcing functions accelerate our learning and push us into defined criteria we can use for decision making.
Work backward and forward
The default method of problem solving for most of us is something akin to the scientific method we were taught in grade school: hypothesize, design test, run tests, analyze results, conclude, and repeat.
For our marketplace at Choose Energy, a hypothetical process might look something like this:
- Problem: 50% of customers are not getting the energy service they selected on our website
- Hypothesis: customers aren’t completing the offline steps required by our partners once a lead has been passed through due to confusion
- Test: non-API partners v. API partners in the same zip codes over the same periods
- Analyze: conversion rates, customer service costs, etc...
- Conclude: require all partners to be integrated via APIs
This method is useful, especially if you plan on deciding on just one particular area of your product. However, it optimizes for the practical and available versus what could ultimately be more impactful.
By working backwards, you open yourself up to a wider range of possibilities and put the perfect solution for the customer at the heart of the process. In reverse it looks like this:
- Problem: 50% of customers are not getting the energy service they selected on our website
- Desired Result: Customer enrollments should require ZERO extra attention and have 100% confidence in the product they’ve selected once they’ve left our marketplace
- Forces that impede our process: Customers are unsure or unaware if their enrollment is complete once they’ve left our site. Plans are displayed in a complicated way. Customers aren’t sure if they will lose power if they don’t switch correctly. Etc...
- Solution: Build and test products that help customers identify the perfect product for them, make them feel secure in their choice and enrollments are 100% complete by the time they leave our site.
Once we figure out our desired results, we can focus on the things that we need to put in place to make it happen, but also on the obstacles, we must remove to create change.
Inversion isn’t better, it just provides you with a broader set of solutions in the event you are uncertain about the exact solution needed to solve a customer problem.
Customers aren’t just for feedback
Software is temporary, but meeting customer needs are advantages forever.
Customers see your solution as a part of their business, therefore the more you keep them informed of your plans moving forward the more connected they feel. We've seen this play out with public roadmaps from companies like Buffer, Front, and Atlassian.
One of our biggest competitive advantages at Choose Energy was our ability to maintain close relationships with our partners to meet their needs.
We had access to talent in engineering and marketing that they did not, we showed them what was possible beyond their capabilities. By bringing those teams into our conversations with partners, we were able to have a holistic discussion around our product strategy.
This open dialogue around marketing, products, and analytics allowed us to charge a premium for our service and keep customers happy when things didn't go according to plan.
One note on that last sentence, great products, and the companies behind them create opportunity from distress. If your customer isn't satisfied, go out of your way to the largest extent possible to make it right - you'll be rewarded.