About this episode
Sometimes DIY UI/UX design only gets you so far—and you know it’s time for outside help. One thing prospects from SAAS analytics and data-related product companies often ask me is how things are like in the other guy/gal’s backyard. They want to compare their situation to others like them. So, today, I want to share some of the common “themes” I see that usually are the root causes of what leads to a phone call with me.
By the time I am on the phone with most prospects who already have a product in market, they’re usually either having significant problems with 1 or more of the following: sales friction (product value is opaque); low adoption/renewal worries (user apathy), customer complaints about UI/UX being hard to use; velocity (team is doing tons of work, but leader isn’t seeing progress)—and the like.
I’m hoping today’s episode will explain some of the root causes that may lead to these issues — so you can avoid them in your data product building work!
Highlights/ Skip to:
(10:47) Design != "front-end development" or analyst work
(12:34) Liking doing UI/UX/viz design work vs. knowing
(15:04) When a leader sees lots of work being done, but the UX/design isn’t progressing
(17:31) Your product’s UX needs to convey some magic IP/special sauce…but it isn’t
(20:25) Understanding the tradeoffs of using libraries, templates, and other solution’s design as a foundation for your own
(25:28) The sunk cost bias associated with POCs and “we’ll iterate on it”
(28:31) Relying on UI/UX "customization" to please all customers
(31:26) The hidden costs of abstraction of system objects, UI components, etc. to make life easier for engineering and technical teams
(32:32) Believing you’ll know the design is good “when you see it” (and what you don’t know you don’t know)
(36:43) Believing that because the data science/AI/ML modeling under your solution was, accurate, difficult, and/or expensive makes it automatically worth paying for
Quotes from Today’s Episode
The challenge is often not knowing what you don’t know about a project. We often end up focusing on building the tech [and rushing it out] so we can get some feedback on it… but product is not about getting it out there so we can get feedback. The goal of doing product well is to produce value, benefits, or outcomes. Learning is important, but that’s not what the objective is. The objective is benefits creation. (5:47)
When we start doing design on a project that’s not design actionable, we build deb
