Join smart, curious folks to get the Data Ops 📊 newsletter each week (it’s free!)
Zach Lloyd wrote this short piece on the biggest mistake he sees engineers make. What is it? Moving forward with too much work before they get feedback that they are on the right track.
As Zach puts it, when this happens:
We end up in a position of dealing with the Sunk Cost Fallacy where it hurts to abandon the work already done in order to get back on track – if we aren’t careful, we’ll end up shipping the wrong thing because we didn’t want to swallow the sunk cost.
Why does this happen? Lots of reasons, and the core one is that people are proud of what they do. The farther along they get on an idea without feedback, the more likely it is that changing their idea will feel like a defeat rather than a redirection.
Start prototyping immediately
“But this is code”, you say, and “we should trust software developers to build software.” Yes, I’m absolutely in favor of letting smart and motivated software designers innovate with software. We also should stop them as soon as possible when they are working on something that might not add value.
A common way to express this problem is something called the “cone of uncertainty” – essentially, the idea that you have much more variability in cost and time at the beginning of the project than at the end when you have a solid agreement on what to build – and we need an easy way to go from less certain to more certain.
How do we find out whether we are on the right track? Before writing code, we should be doing very simple prototyping. Our goal: to get the logic of a flow, or decide on the basic structure of a feature, or to play with an idea before it’s figuratively set in stone.
Making things deliberately lo-fi
Google’s Jamboard is a great way to test your ideas while keeping things very simple. In fact, it’s very hard to make things complicated while using Jamboard.
Take this simple example of a login that gets information from a back-end service, and then presents a button with a label.
You could build a complicated framework to make this happen, or just draw a picture to imply the process. Instead of asking a developer to build, getting a result back, and not knowing what we see, we can build a few prototypes that display visually what’s happening.
The overall process looks like this:
-
Build a basic prototype for understanding (timebox to 1 hour)
-
Update, fix, and redraw
-
Share with team members for understanding
-
Go back and build a low or high-fidelity sketch
-
Finalize with real use cases and we’re ready to build
When the group agrees that the prototype is heading in the right direction, we’ve reduced the cone of uncertainty significantly. Note: prototyping doesn’t replace a great product or feature requirements document. It does make it easier to get to a PRD everyone can support.
Why prototyping?
It’s simple. You get to the core of the idea faster. Whether you are using paper prototyping, building a digital sketch, or drawing on a whiteboard, prototyping gives you a way to talk about an idea before you’ve got so much invested that you don’t want to change.
Using a deliberately lo-fi idea also makes it so you spend less time on the prototype itself. It’s a hack to getting to a better feature.
What’s the takeaway? Using the time in “norming and storming” to draw simple pictures and break the feature process down to a set of decisions before development work is started in earnest builds a better product feature.
A Thread from This Week
A Twitter thread to dive into a topic
When dashboards don’t track to shared understanding, they can amplify the gap between departments. This makes it all the more important to agree on definitions.
