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.
Create your profile
Only paid subscribers can comment on this post
Check your email
For your security, we need to re-authenticate you.
Click the link we sent to , or click here to sign in.