And now, let's talk about MVP (minimum viable products) and why building a data product in this manner may be a very expensive, slow way for your team to learn.
It's pretty simple: MVPs sound great. And they can be great, in terms of focusing on a rapid way to try things, get feedback, and make improvements.
Except most places don't do that.
Most places just keep adding the next item on the list, never subtracting or reevaluating the truth about the value of their MVP. Because there's no time, and the users/biz needs it right now.
MVPs say "fast!" and that sounds good.
The thing is, an MVP is really your stakeholder—or you—saying to the team, "we don't know what the user needs exactly, let alone whether they'll even touch, adopt, or buy the data products we want to build. So let's try something and see what they say."
Saying "we don't know," is awesome as it opens you up to possibilities. The thing is, there is a much cheaper and faster way relative to MVPs to learn what users need, and how you'll need to position your data in a way that it changes their lives to a point that they'll become dependent on your insights and technology.
It's called user research.
Not too exciting?
Well guess what: most of you do very little of it. Most of you have no routine program for it, and you spend most of your time building and guessing instead of learning about the your users' problem space, how decisions are made with data today (or would be tomorrow), and how your solution needs to fit into THEIR life.
(After all, it's not for you - it's for them.)
Learning faster is a significant competitive advantage for your team and org.
In fact, it—not AI—may be the #1 competitive advantage of your entire company if your team knows how to react to the data(!) you capture when talking to uses.
Look, you're smart: you already know this is probably a better approach. Why?
Because I'm talking about doing data-driven work.
Not guessing.
You call for this all the time: are you also practicing it with your team?
Did we forget that qualitative data (aka our research findings) is also data?
You know that rapid learning mean less time wasted on making the wrong solutions.
When your team really understands the user's problem space, their best work usually emerges.
UX research, particularly the qualitative 2x1 or 1x1 type interview/shadowing style ethnography, is essential if you want to stop guessing, and start reducing the risk of putting out another data product that won't get used.
Chances are, your bias is always going to be towards "building something" or wrangling the data, or building the infrastructure that you know you'll need "no matter what comes out on the front end."
Because BUILDING is easy to measure.
Because doing technical work and wrangling data and making models FEELS like progress, and one can't easily measure the value of "listening to users talk."
However, you can measure the impact of failed data products, over and over.
The kind that don't get used.
The kind that users don't trust, don't care about, or can't use because it's just too damn complicated.
The kind that were never informed by any user research up front.
My #1 advice for most of you is to spend more time with your users: watching, listening, learning, and inquiring. Because this is how we reduce the risk of making bad products, and increase the playing field for innovation to occur.
This goes for ALL the members on your team.
These customer/user exposure hours are critical; and not just for your UX / design staff if you have them on your team.
In fact, if you do have design/UX professionals on staff who are trying to "own" research, and aren't beating the walls down to drag your technical and data team members in to observe, facilitate, and participate in research, they're not doing their job properly.
Research is where good design begins: with the people we serve who use our data products.
it's about knowing their attitudes, concerns, decision making processes, workflows, perspectives, and past behaviors—so we can do better things with the data we have.
You just need a repeatable habit and program in place for doing research that includes your whole team. It's the #1 thing that's going to help you and your team innovate, and prevent you from relying on the "guess, build, get lucky" routine (which sounds about as data-driven as the jazz concert I'm going to play this week.)
In the long term (maybe not so long actually), your users will thank you—and you'll be on your way to doing human-centered design instead of talking about it.
When users are happy, the business value usually tends to follow pretty quickly.
Photo by Franco Antonio Giovanella on Unsplash.