I'm just figuring the whole product and problem-driven thing out. Maybe I'm going in the wrong direction, but discoveries on the road are quite interesting.
So we are tackling a product for the customer (data science department in an international logistics). I've been with that customer for more than 3 years now, they are more like a dear friend now.
Our normal line of work is around a mix of consulting and software engineering. We do workshops, get requirements, build a solution, deploy and maintain it.
This time things are different. The customer asked us to treat the project as a product. Think about the long-term impact past-the deployment, think about solving the real problems and improving the data science processes throughout the organisation. I wanted to treat it as a product. So we accepted the mission and started doing customer interviews, talking to the data scientists, operations, data ops, heads.
We didn't pitch any solution in the interviews simply because there was a mental block and no solution to propose. Just follow the rules outlined in Mom Test: listen, focus on the past experiences and dig in.
There were a few surprises. I have worked with some of these people for more than 3 years, but never had time to sit down and actually listen. There were nuances to the known problems.
After soaking up enough problems a new solution has surfaced. The one with fewer risks, faster iterations, and a slightly higher chance of success.
The presentation of our findings was interesting already: "Remember the solution that we originally proposed and you liked? Here is why and how it was going to fail. Let's do something completely different instead!". We had approval from the customer.
Today I'm presenting the first tangible artifacts. It is a tiny mess of a few Python scripts, a Flask web server, a potential UX prototype in Figma, and a Roadmap.
It is the most minimum valuable product that tries to attack the core problem, while de-risking major integration points.
No CSS styling, plain HTML. Only a single UI screen (affordances on that screen are thought-through, though). There are other UI screens possible and potentially important in that project, but I didn't even think about them, so I will not be able to present anything outside of the one single screen.
I'm extremely proud of that!
The reason is - we focus on solving problems from the long-term perspective. Most of the important Data Science and Machine Learning problems for that customer could be handled by one giant HTML table (sourced via a number of rules from different source code repositories). This is a theory we need to test in the real world as soon as possible. Everything else is irrelevant.
If we try to prettify things - this will make the first deliverables nicer, but will not add anything substantial to the list of the problems solved. It will just delay the test results. This is a waste.
If we ponder about the secondary screens - that would be a premature optimization and a waste of time. We don't know if the primary screen works well enough. We have to validate it and the core product idea as soon as possible. Everything else is a waste. It could even lead us to solving the wrong problem.
This is counter-intuitive to what I've been doing before but feels very liberating in a sense. Focus on delivering long-term value to the customer. Ignore everything else for now.
I came up with a heuristic for starting new products. It is counter-intuitive. If Web UI in first iterations has custom CSS styles, fonts, and UI elements, then I didn't have my priorities straight. I wasn't rigorous enough in identifying the root problems, coming up with a solution, and the leanest possible way to validate it. Instead, I probably got distracted and wasted time on the UI.
Pretty UI in the first iteration - then to /dev/null the project goes. Pretty UI means that my discipline has slipped and product validation wasn't the focus. Bigger mistakes could be lurking beneath.