As a member of a Product team, it's extremely easy to fall into one of two camps. You either miss the forest for the trees, or the trees for the forest. We either become so focused on making small, low risk changes to our products that we never undertake larger, high risk tasks. Or we become so focused on staying on top of the next big trend, that we leave entire swaths of our product in decay. So the question is, are you soaring over the redwoods or simply examining a tree's root structure?
Hello from the helicopter
For those that find themselves at 8,000 ft, it can be hard to image a life not spent admiring the broad landscape of forests. Whether your forest is a SaaS product or a physical one, those up high spend most of their time planning features that are on the 'bleeding edge'. You know your competition and the landscape in which your product resides. You're aware of the newest technologies that are allowing startups to take ground quickly. But you won't be caught flat footed.
Those who are soaring above the trees are mostly focused on building the sexiest, risk-taking features which could potentially change the game for the company. Why focus on what we built last year when we could be opening up a massive new user segment by just adding this one feature? The mentality is that time spent on maintaining old features is time wasted. If no one is actively complaining about the product, then we shouldn't be asking about what they don't like. We should be giving them the features that they didn't even know they wanted yet.
The danger in this mentality is that it often causes older, more fundamental features to be ignored in lieu of the latest and greatest items. There isn't anything inherintly wrong with building features that could increase revenue by 10x. However, if the user experience in your application is suffering because no one is taking the time to pay down technical debt, then your forest could be rotting from the ground up. The problem with staying in your helicopter and keeping a view exclusively from above is that you often miss out on the things that are causing discomfort and annoyance for your customers. New features can do a lot to please a client, but if they can't complete simple day-to-day tasks without friction, then they probably won't be around long enough to be wooed by your next feature set.
I'm a full-time tree surgeon
One of my favorite simple job descriptions is that of an arborist. You see, arborists get to call themselves 'tree surgeons', which I find amazing. It brings to mind a dinner party in which one person is describing their job:
Joe: So Jim, what do you do for a living? Jim: I'm a surgeon actually. Joe: Oh, a fine profession. My brother is a surgeon. Are you over at United Hospital? Jim: No, I'm out at the Grand National Forest. Joe: Huh. I wasn't aware that there was a hospital out there. Must be pretty small. Do you focus mostly on hikers and such? Jim: Coniferous trees, actually...
See, arborists are focused on one thing and one thing only, the health of individual trees. So maybe you aren't up in the clouds like those other guys, maybe you are down in the mud with a microscope, looking for the things that could be ruining your trees. You spend your days going from tree to tree in your forest looking for potential issues which could cause problems down the road. No bug fix is too small, no feature tweek too fringe. If one customer is having issues, then we need to make sure that their experience is as seamless as possible. We don't have time for huge new features when our support queue isn't at net 0.
The Product team members that are down in the muck are usually those that put an extremely high priority on customer experience. If a customer has to wait more than a few seconds to download an entire database, then they might leave. (This sort of thinking might mean that you are possessed by a chicken). If the product backlog has more than a handful of tiny feature changes, then you're doing job wrong. Those that find themselves in this camp use these sorts of excuses as a reason to not take risks on big, new features. Whether it is because of a lack of customer understanding, or an aversion to risk, they are firmly planted on the forest floor.
One of the primary pitfalls of this sort of thinking is that a product can end up extremely stable, but horribly out of date. Because such a priority was placed on improving the underlying framework of the platform, no one took the time to see what the competition was rolling out. This can cause an entire product to collapse under the sheer weight of stagnation. With no new features, customers slowly fall off in use as they find new interests elsewhere. Yes, no one has seen an error screen in 6 months, but most of our former user base hasn't logged on in a year. It's extremely dangerous to pay such close attention to your small group of trees that you fail to see the logging operation taking out acres of your forest at a time.
Joining the Royal Forestry Society
Let's say you find yourself firmly planted in one of these two camps. The question is really whether there is any sort of middle ground. What is there to do when you know that you need to either start taking care of your trees or just take to the sky? Well, it's time to join HM The Queen in the Royal Forestry Society.
The RFS is one of the oldest membership-based orgnaizations in Great Britain focused on woodland management and forestry education. What makes them the perfect analogy for our middle ground is that they are focused on both the health of the individual trees and the overall wellbeing of the forests. Plus, they are somewhat associated with the British Royal Family, which is a big deal to some people I guess.
Those involved in the field of forestry need to be able to take a microscopic and hollistic view regarding the wellbeing of the forest. It doesn't do to focus on only one or the other. The same can be said of the preferred place where most Product Managers should find themselves. Yes, expanding revenue opportunities is amazing, but so is ensuring that customers have a great user experience. Figuring out how to balance this information is extremely difficult, especially for small Product teams. Dealing with the constant input of new features comingled with the paying down of tech debt is sometimes mind bogglingly frustrating. All I can offer at this point is a few simple observations:
- Know that customers do care about their experience. Up to a point. What many people tend to forget is just how forgiving most people are with the products that they interact with daily. The largest companies in the world know this, and they know that changing from one product to another is hard. That's why they put only a slight importance on ensuring that you have a trouble-free experience. Apple, Google, Microsoft, they all understand that most people will deal with a little discomfort or annoyance with their products every now and then. As long as it works most of the time, people will forget the negative experiences after a while.
- Stagnating your product can cause you to enter a death spiral. If you're not careful, you can miss major moves that are being made by your competitors, potentially losing out on major shares of the market. You need to stay on your toes when it comes to the cool, new features that other companies are launching. And if no one is launching something new, then you should be looking for a way that you can leap ahead while you have the chance.
- Mixing together periods of risk-taking with periods of paying down tech debt can work extremely well. If you are able to identify one or two large cornerstone features that could turn into major revenue, then you should focus on those. If not, then you should take a short breather to pay down your tech debt by fixing bugs and maintaining old features. While your Development team is off improving the UI/UX of your product, you can find that hot new thing that people will want for months to come.
Where do you find yourself right now? Are you taking in the view from the Chopper 4, operating on an oak tree, or hanging out with the Royal Dorgis? I'd love to know what you're doing to make your product better.