WHY MOST AI PRODUCTS FAIL?
WHY MOST AI PRODUCTS FAIL?
Embedded Files
Created with Midjourney AI
AI has the potential to revolutionize the business world. Still, the reality is that many AI products fail, which is especially true in the B2B context, where the stakes are higher and the challenges are more significant. So, why do so many AI products fall short of their goals?
Missing Business Case: To succeed, not just an AI product but all products need a solid business case. It is a more significant risk in AI products because organizations often initiate AI products for the sake of starting AI products. It is the PM's responsibility to make sure that there is a clear business case.
Poor Data Quality: AI depends on data to make decisions and deliver results. If the data is of low quality and accurately represents the target population, the results will be inaccurate, and the product will fail.
Technical Challenges: AI products can be technically complex and require specialized machine learning, data science, and software engineering skills. Without the right resources, organizations may struggle to deliver successful AI products.
Integration Issues: AI products need to be integrated smoothly with existing systems and processes to deliver results. Without careful planning and execution, organizations may struggle to integrate AI effectively.
Change Resistance: AI products can change existing systems and processes significantly. If the organization resists change, the product is more likely to fail.
Misalignment with Business Goals: AI products need to align with the goals and objectives of the business to deliver meaningful results. Without alignment, the product can become disconnected from the business and fail to deliver the expected outcomes.
PRODUCT HELP WITH PLACEHOLDER UI ELEMENTS
PRODUCT HELP WITH PLACEHOLDER UI ELEMENTS
UX consistency between different modules was one of the most important criteria we had early on. We wanted every module to feel similar so that different users from different departments can benefit from these modules even if they are not trained to use it.
As a small startup, we did not have UI designers, support team, or trainers so we needed to make our UX as simple as possible and consistent across different modules. This limitation created wide empty spaces in certain parts of our UI.
We decided to use this big empty spaces to show our users hints on how to use that specific module.
Our users are employees of large insurance companies so they rarely have any time to read through documentation, watch videos, or follow interactive walk throughs.
Adding a page long explanation on how to use the module definitely defeated the purpose. This allowed us to think about what's the most important thing that we want the user to know about this module and how can we communicate this message in a few sentences.
I think this simple change was significantly effective on delivering the consistency and ease of use, we started to receive significantly fewer questions from our users.
Is there similar strategies you developed? Let me know at inbox@anilcelik.com
WHAT THE USER DOES AND HOW THE SYSTEM REACTS
WHAT THE USER DOES AND HOW THE SYSTEM REACTS
About 7 years ago, my technical co-founder at UrbanStat asked me to check out BDD. She believed that we could use it to write our PRDs, although I first thought it wasn't really that much different than writing Gherkins, it had some obvious benefits to it:
We didn't need to write test cases/acceptance criteria separately, PRD included our test cases
BDD encouraged product managers to think about how the system would react to user actions. This meant:
less ambiguity in the functional requirements
the developers were more informed about the requirements
the developers and QAs were fully aware of expected reaction of the system before they even start the implementation
Although BDD was not designed to write full user journeys, after some research and online discussions with other product managers, we found out that a lot of companies actually use some form of BDD to write PRDs. We should probably come up with a different name sooner than later!
How does it look like?
How does it look like?
I hate when tutorials give you the most simple example. I often find myself in these situations where I look at the tutorial and immediately come up with a scenario the example may not work for one specific case I have in my mind. So I'll share an actual example from a real product:
Scenario 1.1 - User add a new WMS map
Given the company administrator is authorized
And the company administrator is in "Add Map" module
When the company administrator presses "+" icon on top right corner
And the system creates an empty form with following inputs: Map Name, Map Type, Map URL
And the company administrator types the name in "Map Name" field
And the company administrator selects "WMS" from "Map Type" dropdown list
And the company administrator types the URL in "Map URL" field similar to this "http://beta.sedac.ciesin.columbia.edu/mapserver/wms/gpw2000 "
And the company administrator clicks "Save"
And the system asks to confirm the "Save" operation
And the user clicks "Save" on the confirmation window
Then the system saves the map
And the system shows a confirmation stating that the save is successful
And the system adds the layer to the "Layers" widget
Although in this specific example there is a single "When" and single "Then", some teams prefer to have multiple "When" and "Then" while some teams just stick to one to mark the most important steps of that customer journey.
In this specific example, you see that we describe the state of the system and the user, what the user does and how the system reacts to certain actions. Scenario doesn't end when the user completes their last action, we keep going and explain what happens after the action is completed.
In BDD it's advised that the language should be more declarative rather than imperative. However, I personally believe that more imperative style gives the developers more clarity and enough flexibility to implement the solution however they like. For comparison a real BDD for the same scenario would look like below:
Given the company administrator is in "Add Map" module
When the company administrator adds a WMS layer (with a name, name URL)
Then the company administrator sees the new WMS layer in "Layers" widget
Although this explains what we want to achieve, it doesn't explain the nuances that we expect from the scenario e.g. how the system reacts what happens between main actions, reactions, and the end result.
What do you think?
Page updated
Report abuse