Four Steps for Developing Successful Product Features
Before I became a Product Manager I spent the first five years of my professional career as a software engineer. For the duration of those years, my focus was mainly on the delivery aspect of software development.
Even after I made the transition into a product role, it’s only really within the last few years have I really begun to appreciate how important the discovery part of Product Management is, how that changes and how to think about success. Moving to success measures, based on actual business impact, intuitively feels good but is it really helping us build a better product?
1. Become a Product Owner
As a developer my frustrations were usually stemming from the feeling that the developer team ended up wasting time due to having unclear backlog items, and that a failure to properly create thin slices of functionality in projects hindered an agile mindset.
As I transitioned into my first product owner role, these types of inefficiencies became my primary focus. How to ensure the team had clear requirements and acceptance criteria, as well as getting a good agile process in place that ensured we could deliver production quality solutions in iterative milestones.
When I today reflect on this time in my career, I value the skills for project management that I developed. The big blind spot in my thinking back then was the risk, for what Eric Ries in the book The Lean Startup, describes very succinctly as achieving failure.
Achieving Failure: successfully executing a plan that leads nowhere.
Moving fast is important, but even more important is to make sure you are moving in the right direction.
2. Create Business Goals for the Product
As an engineer, my default perspective used to be to view software projects as a game of chess. Games can be more or less challenging, but given that you make the right choices — in the end there is a deterministic path to success.
My understanding of agile processes were mainly from the perspective that estimations are really hard. Delivering working software regularly meant that in case budget or the project timeline was running out, then we could always stop at a stable point knowing that we’d covered the most important pieces first.
As long as the project was on track though, delivering according to the specification and passing the acceptance criteria was equivalent to success.
What didn’t really sink in for a long time was that even when doing everything right according to plan, a project could still be a complete failure given that it failed to deliver the intended business results. In the end, the only really meaningful measure of success is in actual impact on business goals.
No matter how smart you are — you can oftentimes not know beforehand whether a feature will have the impact you hope, and the value of agile processes as a Product Manager are thus to a large extent as tools to let you test your assumptions as early as possible to find out whether you are on the right track or not.
This inherent uncertainty is also why prioritizing a feature as a Product Manager, oftentimes is more akin to betting on a poker hand than it is choosing your next chess move. Sometimes you make all the right choices given your available information and will still not get the impact you had hoped for.
If it is any consolation, the vice versa is also true.
3. Develop Measurement Criteria
For those reading this post so far, and are up to date on modern Product Management theory by thought leaders such as Marty Cagan and others, this might all seem quite trivial. OKRs, impact mapping and so on, are all well known techniques meant to address precisely these types of issues.
What interests me though is that even with my previous more narrow understanding of success, generally the teams and companies I’ve worked for have been very successful. Do we really need these measurements then or can we rely on good business sense instead to guide us?
Since it is also generally easier to track output in this regard, than being able to A/B test or in other ways, measure that a specific feature actually drove impact. The interesting question really is this:
Can we specify the circumstances when good judgment isn’t good enough, or are modern Product Management processes and practices to a large extent hot air?
These are my Principles on Measurement. The way I think about this currently comes back to the question about the level of uncertainty in the products we are building. To quote The Lean Startup again:
A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty.
When working in conditions of extreme uncertainty, then the follow-up where we measure the actual impact becomes vital. We focus on our biggest assumptions and testing them is the key to lessening the uncertainty.
For a lot of features being worked on though, I would argue that we don’t have that level of uncertainty. Even if the company as a whole would qualify as a startup, there will be a lot of features where the problem space already has been thoroughly explored during the last decades, and time spent on following up on the impact is likely better spent on other topics where the uncertainty is greater.
If you are not working on the forefront of a new technical paradigm, your product will most likely have a mix of attributes that are basic requirements expected for the type of product you are offering, and a few important attributes that are your Unique Selling Propositions (USPs), what you use to separate yourselves from competitors. Breaking down features this way lies close to the Kano model, developed by Noriaki Kano in the 1980s.
Using the Kano model as a framework for reference, I would suggest that for a lot of features corresponding to basic needs, we oftentimes understand the problem space well enough not to have to bother with much follow-up. This goes especially when the feature, as indicated in the diagram, isn’t expected to generate much more satisfaction if improved upon, once it has reached an acceptable state.
For the more explorative delighter feature, that ventures out into unexplored territory on the other hand, this is where you should have a clear idea how to measure the impact, and continuously iterate on the feature to drive the KPI in question further.
4. Tie it all Together
In a few sentences then, when is it important to go beyond mere acceptance criteria, and look into measuring post-deploy success criteria based on actual business impact?
- When you are exploring a domain where you can’t have a good sense of the impact without actually measuring it
- When the impact in question is expected to be strongly tied to how well the feature was implemented
If neither of these are true though, then your time might be better spent moving on to a feature that is likely to fulfill these criteria.
