In my previous blog, I shared some comments on a gap that we see often times between Marketing and Tech.
After the launch of a brand new digital or connected product, marketing wants the product to shine in campaigns, establish partnerships and respond to the first feedback of (early) customers.
On the other hand, developers are happy that the product is live, the pressure towards a launch has vanished, so they can fix the corners they had cut, and worry about technical debt.
Now, what happens before a launch?
When a new and innovative product is conceived, everyone is excited. A vision for the product is established, a Product Owner gets assigned, a Scrum Master will organize an Agile development team, and off we go.
The product will be described in terms of features and benefits, and what it will do for customers. A list of ‘Must have’, ‘Should have’, ‘Could have’ and ‘Nice to have’ functions and features is composed, which serves as the basis to define an MVP.
A Minimum Viable Product is, as the name suggests, the minimum product specification required to have a viable product. A product that has a reason (or right) to exist. The idea behind an MVP is that you want to generate feedback from the market as early as possible and have the market determine where priorities need to be set for further development. This limits the risks of spending development resources on product development on products that the market does not need.
In practice, we see the following: as soon as the MVP has been determined, everyone is excited to build this MVP. But the reality is harsh, progress is not going as expected. Things turn out to be more complicated, it takes longer to build, the user stories were not that clear at all.
And pressure increases
Time is ticking. Developers have other projects coming up to worry about. The number of sprints initially planned for the development is running out.
So we have a look at the MVP. Features and functions that were considered essential will now be downgraded as ‘nice to have’. Which is a euphemism for: let’s do this later. Which in itself is a euphemism for: this will never happen. Of the functions that remain classified as essential, a few must be dropped.
And then: time’s up. There is the product. More minimal than originally conceived. Maybe even half-baked. Veiled in promises of future upgrades and improvements.
The reactions to the product are lukewarm. Which is to be expected, because everything that was ‘nice to have’ has been scrapped. And therefore, there is no reason for a customer to think of the product as ‘nice to have’.
The uptake of the product is not what was hoped for, the press is not as enthusiastic as they always seem to be when Apple launches a product. The development team moves on to the next project, maybe with some resources left for some bug fixing.
And the question arises: Is this product viable?
Recognize this? Within our networks, we hear this a lot. And honestly, me too. I have also released products that have not generated my biggest pride.
Let’s get in touch. We have some ideas how you can easily spice up your product with minimal development effort. So you can stick to the core of your development, and we add the bells and whistles that makes your product ‘nice to have’.
Example? For a supplier of connected smoke detectors, we added the feature that they re-order their own replacement batteries. With ZERO coding efforts for any of the parties (smoke detector supplier, payment provider, battery fulfillment partner).
While developing a smoke detector, having the device reorder its own batteries would typically be a function that would initially be scrapped, partly because it is complex to organize the whole chain. This is where Olisto comes in …
