The most natural force in product development is to deliver additional user value in the form of new features. This is generally good. By not riding on a previous wave, you're proactively looking past the status quo and making something that's more likely to withstand disruption.
By saying yes to more features though, you are accepting the tradeoff in additional product complexity - both for usability and maintenance. In the short term, adding new details and surfaces into the product feel obviously useful and worth it. Your most loyal users thank you for listening. Your organization’s leaders celebrate you for realizing incremental gains that are harder to come by for a mature product. Maybe they even praise your outsized impact relative to investment. In the long-term though, you’ve inadvertently said yes to hundreds of small new local improvements and new surfaces. Very quickly your simple and approachable product becomes highly complex and oriented towards power users who have built up their understanding over long-term usage. New users can only ever use your product if they are motivated enough to overcome the learning curve to become power users. This puts a bottleneck on growth, with some short-term relief provided by investments in user education and onboarding flows. The upside here is limited, because you haven't tackled the real problem of product complexity.
This is a debt most teams know they are accruing but are rarely conscious about. They know this debt exists but they can't see it. The cost to tackle it proactively isn't one they're willing to fund since it is harder to measure their impact on the more immediate KPIs. Once it has accrued to the point it hurts, a fix usually comes in the form of a major refactor or redesign, that takes far longer to launch than you can anticipate, because existing revenue streams are sensitive to them and they are funding your efforts after all. For a host of products, it's often too late to navigate this change when it is in reaction to growth plateaus or dips in usage, which are often trailing indicators of complacency. Usually by this time, you'll already have a few disruptors in the market that you're actively combating. Your competitors offer something compelling while far less sophisticated -- simplicity and a low barrier to entry makes them as approachable as your product once used to be. In response, you're unable to remove features from your existing product, because your existing users depend on it. You're unable to add competitive features before your major redesign, because it increases your debt further and might end up alienating even your existing users. The situation feels impossible and you wish you'd responded sooner.
The System Solution
Having personally witnessed this in more than one situation across multiple companies, I've made sure my teams are chipping away at product debt proactively. The simplest solution I've found is to sign up only a proportion of bandwidth we have available as a team to support upcoming product work. We intentionally maintain slack on the team (10% bandwidth might be a safe lower bound) to tackle product complexity we cannot see yet. We usually spend at least half this time playtesting. This allows us a chance to retroactively identify the issues of people who are more dependent on our products, many that don't look anything like us. The other half of the time is spent simplifying complexity or fixing issues we've found as a part of this process.
Further, as a part of any new product work, I've found it helpful to bake this into our process proactively. To ground ourselves, we first ask: What are the core jobs that our new products/features will be hired to do?
Then, we ask a few more questions to isolate the real issues:
- Are we accidentally signing up to do more than these core jobs? We usually are, and it's easy to make cuts here once we can see.
- Are there other features/parts of the product which do jobs similar to the ones we're just building? Again, we usually do find features that become good candidates for consolidation/deprecation.
If we're intellectually honest, both of these are excellent at reducing debt on your team. When there are competing incentives, it's sometimes important to ask the extreme questions:
- Are we making our products complex because it serves a lot of people, or we doing it because we haven't set the right goals? This is usually a simpler fix and goal reset can start to pivot the team in the right direction.
- Are we adding more features just to warrant this team existing? In many companies, this is true more often than we care to admit. The solve here is to move your pool of talent to a more meaningful part of the business.
Kurt Vonnegut, written originally in The New Yorker, May 16, 2005:
True story, Word of Honor:
Joseph Heller, an important and funny writer
and I were at a party given by a billionaire
on Shelter Island.
I said, “Joe, how does it make you feel
to know that our host only yesterday
may have made more money
than your novel ‘Catch-22’
has earned in its entire history?”
And Joe said, “I’ve got something he can never have.”
And I said, “What on earth could that be, Joe?”
And Joe said, “The knowledge that I’ve got enough.”
Not bad! Rest in peace!”
via Robert Sutton
Bill Gates's definition for platforms is a good way to test if you're using the term correctly to represent the work your product is doing:
A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it.
Companies often create blindspots for themselves when they use research or data science with the myopic view of market validation, since this info is inherently biased towards what people already understand. They chase the short-term value of building a better commodity and cementing their existing position, because they dislike being in the ambiguous position of investing resources in a product that might never ship or see a payoff. Other companies with market leading positions sometimes console themselves by thinking it would be too costly for customers to uproot them and switch to a competitor. This can be a trap, because whereas the disruptor is able to move fast to close gaps in their product, the larger incumbent's delayed reaction risks them not having enough time to catch up because they have many more dependencies to resolve.
Engelbart's talk Improving Our Ability to Improve, covers this topic in detail, and has a lot of seemingly obvious advice that more companies ought to follow. While worth reading in its entirety, here are some parts that resonated with me that I think are important for product teams to value to extend their half-life:
Invest actively in value the market doesn't see yet
Listen to the market to make your product more attractive for customers or to hold your position (make your commodity better), but to remain relevant in the future, you need to also consciously invest in parallel to build what your market doesn’t understand yet (expand outside the commodity that’ll likely be disrupted by something cheaper/better).
Oxymoron: "Market Intelligence." [...] The "market" assumes the dimensions of faceless, impersonal deity, punishing economically inefficient solutions and rewarding the economically fit. We believe in the wisdom of the market and belief that it represents a collective intelligence that surpasses the understanding of us poor mortal players in the market's great plan.
[...] In any case, it is quite clear that whatever it is that the market "knows," its knowledge is fundamentally conservative in that it only values what is available today. Markets are, in particular, notoriously poor judges of value for things that are not currently being bought and sold. In other words, markets do a bad job at assessing the value of innovation when that innovation is so new that it will actually rearrange the structure of the markets.
Don't let ease-of-use limit utility and performance
While you might chase the benefits of ease of use, don’t discount the common-sense payoff that users get in terms of performance when they have to learn some things every once-in-a-while, that translate to muscle memory/ superpowers thereafter.
Going back to my tricycle/bicycle analogy, it is clear that for an unskilled user, the tricycle is much easier to use. But, as we know, the payoff from investing in learning to ride on two wheels is enormous.
There's a gradient of ideas lost when we take extreme sides in discourse. The people we stereotype in our heads are more like us than we think. All it takes is having a conversation; maybe we resist it to avoid finding that our neighbors are quite likable, just like Sahil Lavingia did:
I had assumed that Provo was happy being Provo — white, male, and Mormon-dominated. I hadn’t thought to consider that they wanted change just like I did.
They were envious of San Francisco’s racial diversity (while I complained about how much further we had to go). They lauded the focus on women in the workforce (while I talked about how sexist the tech industry was). They spoke ill of their reliance on cars and the negative effects on the environment, while I spoke ill of San Francisco’s public transportation.
I visited San Francisco last Christmas, and I tried advocating for conservative politics at bars. There is a stigma that certain ideas aren’t taken seriously in San Francisco anymore. I didn’t see that. Just like conservatives embraced me and my ideas, liberals gave me the same grace.
I now believe that both sides are composed of mostly open-minded people that aren’t represented in the NYTimes nor on Fox News nor in the latest viral political Tweet. They’re at home and at school and at work trying to make ends meet. They don’t care about that level of exposure. They are working privately to solve those problems. Maybe you’re one of them! If so, hi!
The term Work-Life Balance suggests a tradeoff between time spent on work and on life, with one borrowing from the other and a balance providing the silver bullet of happiness and contentedness. This is at least a little bit misleading, because while the tasks at work and home are different, how we feel at any moment in time is harder to compartmentalize to a certain part of the day.
What I've found more effective to strive for is better Task-Satisfaction Balance. If you don't enjoy what you're doing, it is much more likely because of the type of tasks you're doing, rather than because of the number of hours you're putting in. At work, doing the types of work you really enjoy are likely to help you do the work faster, whereas that which you find less enthusing or fulfilling consumes all time you have available. The is also true at home. To stop walking the path to burnout, I've found myself needing to catch myself spinning my wheels on mundane tasks and pivot fast.
Companies recognize the emotional appeal inflated titles have on our egos, and far too often have no difficulty presenting prefixes like "Staff" or "Principal" as part of our negotiation, even if the expectations and compensation are no different than less senior roles at the company. It serves as a good reminder that seniority is gained not simply by tenure or checking a few boxes, but by changing how we approach our work:
Labor vs. Influence
When you start your career, a majority of your work product is a function of your own labor. As you grow, while this is still important, your own output is secondary to your ability to work with and influence others, because this allows you to multiply the amount of work produced relative to that which you can produce yourself.
Deliverable vs. Outcome
In the earliest stages of your career, you often take on work that has well defined parameters (scope, timeline and end-state), and your success comes from delivering this as expected and on time. As you advance, there are fewer boundaries set, but more for you to solidify. Next in your career, by knowing just the outcome, you know to define the pieces of the puzzle on a seemingly blank canvas. And finally, you’re defining outcomes rather than being handed them, and because this is more ambiguous to everyone apart from you, you need to set up others to succeed, just like you were in the beginning.
A remarkably simple heuristic from the WhatsApp team to decide if your feature is ready to launch yet:
... design and build features which are obviously useful. If the feature needs explanation, it’s not ready.
I’ve found this guidance from a past manager to be durable to this day, and I often relay it to people who need to contextualize their own performance reviews:
Your performance review with increasing seniority is less a reflection of skill level, but more a reflection of whether your values align with the organization you are within. Take a bad performance review not as a measure of your aptitude, but as a decision point: whether to shift your values to align with the same organization or move to an organization that aligns better with your own.