The Shortest Path to User Value in Product Engineering Projects

A set of questions and mental models I've found useful to challenge the status quo and ship value to users faster

Welcome to the Captain’s Codebook newsletter. I'm Ilija Eftimov, an engineering manager at Stripe. I write this newsletter article on tech industry careers, practical leadership advice and management how-tos.

Zero interest rates are gone. It's a budget-constrained environment. That's not to say that budgets were not important before, but when money was cheap to borrow, it was easy to spend. For software engineering teams, this new environment means that now, even more than before, we need a tunnel vision to create value for customers. The craft of engineering is essential, but we need to invest our time and energy carefully. We've entered a time of effective engineering.

As a new engineering manager, I've faced this reality: How can I be effective with my team's time and energy? To arrive at the answer, let's first examine how projects usually begin.

🛫 The usual project start

An idea springs up in the form of a (pseudo) product brief. The team's leads—usually the engineering manager with the product manager and/or tech lead—review it and decide to fund it. It's cross-checked with the other cross-functional partners—it looks good. The EM elects an engineering lead for the project, and together with the PM, they are off to the races.

After some exploration and solution shaping, it's time for a review. They explain the feature shape, its UX, and the execution plan. They say it'll take two months to ship. The PM and the engineering lead are confident in the solution. The technology can support it, stakeholders are aligned, and it's all a go. It just needs a green light from the EM, and it's game on. Do you give the green light?

As an EM, I support my team's ideas. But before I do that, I like to challenge the team to think about shipping value faster. My favorite way is to try to bring the future closer to today.

🎚️ Toying with The Triple Constraint

The CAP theorem (stands for Consistency, Availability, Partition-tolerance) is a popular theorem that deals with tradeoffs in distributed computing systems. The equivalent in project management is the Triple Constraint. This principle posits that in any project, three primary constraints—**scope, time, and cost**—are interrelated. Similarly, as with the CAP theorem, any change to one factor affects the others.

As an engineering manager, I find it interesting to play with these factors. Questions like: how much could we decrease the 'Scope' (e.g., drop features), and what would be the 'Time' or 'Cost' benefits? Or, can we dial up the 'Cost' – e.g., by adding more people to the project – and how much would the 'Time' decrease assuming the 'Scope' remains the same? You get the idea.

The question boils to: in the project's context, what are reasonable tradeoffs? I've been thinking about these 'sliders' lately - how can I crank-up and down the intensity of each of them to bring the desired value faster to our users and have confidence that we're building the right thing for our users.

It's easier said than done. In real life, it's almost impossible to play with these factors like Winamp's equalizer without making your team hate you. Moving resources or timelines of one project also affects the other projects in the organization. While there is no easy way to figure this out, I have found a set of questions that can bring you closer to the truth. It's not a time machine, but it works.

🔧 Solving the Right Problem

We developers get excited to solve problems. Sometimes, we become so enamored by a great solution that we forget the problem in the first place. But how do we know if the problem is worth solving? How do we know if our users truly experience this problem? Or are we just looking for an exciting way to scratch our engineering itch?

Another way to look at this is: if your company had a runway for one last-ditch effort to turn the company around, would this be it? That's too big of a question to ask anyone. Yet the gravity of the question does not invalidate the mental exercise. If you could solve one last problem, how do you know this is the one that will turn everything around? Have you talked to the users? If so, what did they say?

This is the first set of questions to ponder and ask if the problem at hand is the real problem. The questions might appear basic, but in complex systems and products, this is quite hard to deduce. The interplay of complex features can have obvious side effects that can send you down a wild goose chase of building features that no one wants.

So, ask. Because what made sense yesterday doesn't mean it's still sensible today.

🧱 Is this the right solution shape?

OK, we are sure the problem is the one we want to solve. What about the solution shape? What are we basing our solution shape on? Is it user feedback? Maybe we're doing something similar to what competitors are doing. If so, do we truly have the same user demographics? Are we sure that what they want is what they need or expect?

There's no alternative to building for users. But there's a problem with users: they think they know what they need but only know what they want. Remember Henry Ford's 'faster horse' saying: "If I had asked my customers what they wanted, they would've said a faster horse". In other words, never ignore user feedback but discern between what they _want_ and what they _need_.

Taking this a step further, instead of asking them to tell you what they want, how about you think about what they need, build a prototype, and show it to them? For example, instead of creating the actual API, you can show a document outlining the API endpoint(s), the request and response shapes, and the integration with these new APIs. Or take some Figma prototypes and guide the users via a Zoom call (or even a recording) through the UX of the new feature you're building.

Such a nimble approach derisks your investment in the solution's shape by getting user guidance. This not only ensures you're building something your users would use, but it also gives your users the feeling that they're shaping the product together with your product engineering team. And if it doesn't resonate with the users, you've saved hundreds (if not thousands) of hours building the solution.

⏱️ Bring value to users faster

Now, say you've derisked the solution shape, and you're sure users will use what you build. Coding time? Not so fast—we need to think about the execution model. The fact that we have an actual solution shape is great, but we still have to get to it. And I always prefer to find the shortest way to user value, not what feels natural (or best) from an engineering perspective.

The other day, I read a post by Adriaan Mol, the founder of Mollie about shipping software:

Speed isn’t the enemy of quality; it’s the catalyst for it. Shipping fast means you can take more risks, make mistakes, and learn faster. The quicker you get real feedback, the quicker you can refine and improve. Perfection is a moving target, and the only way to hit it is through continuous iteration. Fast shipping fuels better quality over time.

I don't think about speed as a way to shrink the estimations of my engineering team; instead, I think about how to give users value sooner rather than later. So, I try to force my mind to things that don't scale. For example, the most absurd question "Can we do this manually for a few select users?". If we can, let's onboard a handful of beta users, write some automation script that would sort of do the job of the real solution, and see how they like it.

Would they pay for it? Is it meeting their expectations in the context of a beta? What other improvements would they like to see in the future? By doing something (semi) manually, we wet our users' beaks and show them a glimpse of the cool future that's coming.

What if they hate our beta? They might think it's a problem that needs solving, but now, after trying the beta, they realize they're fine without it. If so, we just saved ourselves months of actual development time. Just fold the project and move on to do something else more useful for the users.

They loved it? We double down on the feature and ship the real thing.

Despite our gut feeling, some features might not be as valuable as we thought they were. Thinking about providing value to our users, even in a half-assed way, gives us the ability to prioritize what our beta users truly find valuable.

---

🖖 That’s all folks

As always, I'm eager to hear from you, my readers! If you've read this far, you're awesome - drop me a message, I want to meet you!

Feel free to connect with me on LinkedIn or Twitter and send me a message. I respond to everyone, without exceptions.