Join smart, curious folks to get the Data Ops đ newsletter each week (itâs free!)
Hi, Iâm Greg đ! I publish this newsletter on finding data products and interesting data observations with the goal of finding patterns and future product insights. (Also, itâs fun.) If you need a background on how we got here, check out What is Data Operations?
This weekâs toy:Â an Etch a Sketch-like tool built entirely in Google Sheets. Edition 80 of this newsletter is here - itâs February 7, 2022.
The Big Idea
A short long-form essay about data things
âïž Why prototyping needs to be ugly
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.
Links for Reading and Sharing
These are links that caught my đ
1/Â Make your product easier to buy -Â finding scale is really about finding the answers to how your customers really want to buy.
Solving customer pain is necessary, but not sufficient to achieving customer success. This means itâs really important to know how to remove friction in the buying process (bonus points if you create a repeatable way to do this.)
2/Â Practice active listening -Â in your new conversation, you can listen better and hear more. This First Round article has helpful tips on building the tools for active listening. You have two ears and one mouth - this is a good ratio for how much you need to talk to prospects (hint: let them talk).
3/Â This photo is not real -Â Do you wonder what Disney characters might look like when rendered as photorealistic âpeopleâ? This series questions what weâre looking for when we say we want to experience ârealâ film and also suggests that deep fakes are going to get a lot weirder soon. The âuncanny valleyâ doesnât seem as uncanny now.
On the Reading/Watching List
Some things to watch or read, in no particular order
Watching: The Batmanâs final trailer looks ⊠epic.
Listening:
I recently found the Data Skeptic podcast, which is dedicated to making data science topics easier to understand for the non-technical listener.
What to do next
Hit reply if youâve got links to share, data stories, or want to say hello.
Iâm grateful you read this far. Thank you. If you found this useful, consider sharing with a friend.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.