The Puppy Dog Dilemma (rev2): Evaluating feature requests

24 Sep 2024 - Frans Vanhaelewijck

CutePuppy

This is a revised version of an this earlier post, updated with new insights.

“Fresh Ideas” Friday

It always happens on Fridays, and it goes like this: some team members have scribbled schemes on the whiteboard and are discussing a new product feature. There’s energy in the room, eyes shining with excitement, and I get caught up and join the party. Inevitably, 45 minutes later, we’re convinced this is the one feature that will take our software to the next level.

Of course, everyone knows about the ‘Mom Test,’ and in the back of our minds, we dread that we need to get customer justification first. But still, it wouldn’t cost us that much, right? The rockstar developers even guesstimate they get it done in a day or two.

That’s the time reality sinks in. I know, the team knows, and certainly, the rockstar developers know that things are never really ‘done’ in a day or two. I’ve struggled many times to convince the team that we should do proper product management and planning. I remind them about the other times we went all in new features only to learn a few weeks later we should have done our homework. It sucks having to bring the team around the whiteboard back with their feet on the ground.

I tried many things in the past to make the team realize the true effort it takes to create a new feature. What works best is something I call the ‘puppy dog dilemma.’ Seeing a cute puppy for the first time is always exciting, but adopting it means many years of responsibilities. Below are tips on how to ‘value’ a feature and how to do the ‘completeness’ check when estimating the effort. Also, when can we — and when should we — deviate from this strict discipline?

The forgotten questions

If you’re managing a product roadmap, I assume you know what you’re doing. Like you, I don’t just need answers; I need assurances to questions like:

It’s surprising (and when I see the faces of my team members, sometimes painful) how few new feature ideas survive these simple questions:

(*) By the way, this is perfectly okay. It’s our job as product developers to define our roadmaps—not just say yes to every implementation request from customers but rather design features that solve the underlying root problems (see Henry Ford’s “faster horse” analogy, although it seems he never actually said it: Harvard Business Review article)

The checklist no one talks about

The reality is that new features bring with it a checklist — a list that seems to grow longer with every release. And yet, in the excitement of the moment, I have often forgot about it. This checklist isn’t just about coding; it’s about the ripple effects that any new feature will have on the ‘whole’ product.

Less obvious but also critical:

We may need to integrate the new feature into onboarding materials, updating automated workflows, monitoring and analytics, or even considering how this change might impact SEO or page load times.

It’s exciting to build something new, but these details can make or break the success of a feature. Ignoring them means risking a feature that feels half-baked or causes headaches down the road. So we need to run every new idea through this ever-growing checklist and make sure we’re not just adding another puppy without understanding the responsibilities that come with it.

Never waste a good crisis

Early in my career, I noticed how some managers seem to thrive on a good crisis. You know the type: the crash on December 26th justifies calling the team in on short notice to fix a critical problem. There always seems to be time and budget to repair things (during the Christmas break) but never time to solve the root cause of the issue (early January during normal work hours). When I became a team lead, I wanted to avoid that and created a public list titled: “Things that will one day come back to haunt us.” We keep a list of weak spots in our product and operations that one day could be the reason for a midnight crash.

The team realized I was serious when I gave them the authority to allocate a minimum number of story points to tackle the most urgent items from the list. We know the payback period is measured in months, but I can guarantee you will see the impact in terms of better stability, fewer crashes, and hopefully no data loss or security breaches.

If your backlog list is growing, you don’t talk enough with your customers

I’ve written before that product backlogs tend to become longer all the time. More ideas are added to the list than you can ever implement. In a previous blog post, I mentioned that you should accept this and learn to live with it. However, after reading the title of this paragraph in another blog post, I realized that this might not be the right approach. It’s ‘out there’ in the real world where our product succeeds or fails, not within the walls of our office.

There are many techniques to ‘value’ new feature requests. Determining the Return on Investment (ROI) of a feature helps estimate the payback period for the investment. I’ve learned to be very cautious about returns that take too long. A lot can change in six months: customer reorganizations, new technology, shifts in the economic situation, and even changes within your own team.

Not all feature requests can be calculated: improving usability or making the app faster impacts the experience of the end-user, who might not be the person deciding on budgets and upgrades. Yet somehow, focusing on these improvements feels like the right thing to do.

Building great products isn’t about adding more features; it’s about adding the right ones. I’ve been caught up many times in the excitement of new ideas, the pressure to keep up with competitors, or the desire to make people happy. But product management means:

I printed a picture of a cute puppy and hung it on the wall. When relevant, I point to the ‘puppy dilemma’ picture to remind us to consider all the potential costs and benefits before making a decision. Hopefully, this helps you decide what to work on. Please share your comments and feedback.


frans@vanhaelewijck.com