This is part of an ongoing series on principle-driven consulting. Read previous blogs, here, here, and here.
At ZEAL, our goal with every new feature is to satisfy both a great user experience and to achieve the ultimate business outcome. A feature that’s unintuitive or hard to use, can be distracting. A feature that’s time-consuming to produce may not be worth the investment. I like to start with what's obvious. I ask, is there an easier way? I then drill deeper. What will give the greatest impact relative to the effort to get us to a collective goal?
What’s Obvious?
Thinking in terms of “easy” is actually pretty hard, especially for software developers. We like to write code and create new things. We like to be clever. Sometimes we want to see how few keystrokes it would take to solve a problem.
What we don’t always do is focus on the actual problem, and whether there are solutions that are simpler than those we’re considering.
The possibilities might include:
None of these are exciting! None of these give us a dopamine hit, or reinforce our belief in ourselves that we’re creative, problem-solving, coding magicians.
There’s nothing wrong with wanting to flex our skills. It’s completely natural to want to solve a problem with our primary tool. I mean, it’s what we’re paid to do, right? Yes, and…
We can, and should consider other possibilities.
The other day I was in an iteration planning meeting with a client team. We were contemplating a feature that was going to modify some data on a page to include some inactive items, as well as active items. The page also gives the user a way to download the list of items via a link. There was some discussion about all the ways we could make it easy for the user to download this list, which would now include some inactive items. The engineers had a lot of great ideas which involved writing more code, making various UI changes, or possibly changing the output file to have some kind of extra description text. What they didn’t consider was changing the link used to start the download to have text that would tell the user what they are about to download. None of their ideas were wrong, but they also weren’t the most obvious, and simple, approach.
One of my favorite prompts when considering new features, or changes to existing features, is, “What do we want the user to do here?” Sometimes when we put ourselves in the user’s shoes, especially if we have a general understanding of who they are, we get different ideas than when we stay in our programmer shoes.
What’s Going to Have the Greatest Impact?
Impact can be measured in lots of ways but most businesses have some metrics they care about. Knowing what they are for your business, or the business you’re working with, guides you in your decision making.
Working on a new feature for a sales-driven business? What questions might you ask to understand the impact of your choices?
Is writing this code, in this way, going to:
The other side of that coin is the question, “Is there a way to achieve the same goal, with the same parameters, without writing any code?”
Why would I even ask that?!
What if your site could handle 10x more customers by increasing infrastructure resources? If that’s possible, then do the math.
Is “number of engineers” * “cost per engineer time” * “time” more than cost to increase infrastructure resources for the next 12 months? We know for sure that your code is going to change in the next 12 months for a number of reasons. There’s a good chance you’ll have other needs in the future that will also increase capacity. But today you might be able to crank up your infrastructure for a fraction of the cost of engineering.
Something similar happened on a client project. They wanted to increase throughput of a process in their system. We came up with a rough estimate of the engineering work needed to affect the process. We considered the future needs of the system. And then we considered the alternative of cranking up their Heroku dynos. For the cost of the engineering work, they could get increased throughput for 2 years by adjusting Heroku. We knew that we’d be expanding the app significantly in less than 2 years so it made sense to wait for those new requirements before engineering a solution. That was the most impactful choice, in this case, and it didn’t require any code.
Consulting means taking in the whole picture and coming up with the best approach. Good consulting isn’t self-serving, it’s client-serving. We want users to feel success when they use the things we build. We win when our client contacts are getting accolades for their projects. If we’re doing that well, it means we’re seeking the best approach to the problem. Is this the most obvious way to solve this problem, and is it the most impactful way? It’s principles like this that keep our clients coming back. They know our goal is to help them win by always asking, “Is there an easier way?”
Photo by Daniele Levis Pelusi on Unsplash
Are you ready to build something brilliant? We're ready to help.
.jpg)
