What Is A Digital Product?
28 June 2018 |
David Jenkins | About a 3 minute read
I’ve been on client site for the past half year helping to establish their digital function. Something that only really occurred to me later on in my time there, was that there was a pretty straightforward misunderstanding taking place about our products. One that I had assumed everyone already knew the answer to, but on reflection why should they?
When we arrived, they were in a difficult spot; they’d very recently been dumped into a new Agile environment having had some classroom style teaching on Agile and Scrum. They were expected to pick this up and run with it from the new year onwards. However, as we all know, Agile is fundamentally a mindset; building the right product and building the product right. Everyone in the department was coming from a waterfall based project landscape, and so classic “wagile” ways of working were evolving.
As Product Owners embedded directly into the teams, our first goal was to show them how to live and breathe Agile. A big part of this is the ways of working, but for me, the other part is understanding and owning your product. The problem is, if you don’t know what a product is how can you understand it? We started a Product Community of Practice, and the first thing I discussed with them was “What is a Digital Product?”.
It’s all about the customer problem
A product solves a customer problem, and delivers a group of users/customer some benefit/value. In turn, these products will generate revenue or help to sell another service offered by a company. Without a genuine customer need, a product can’t exist/will fail. Products grow and evolve, they can last for many years, and this is one of the ways they are distinct from projects and features.
So what separates a feature from a product? It seems like a blurred line…
The key thing that separates a feature from being a full product is that a feature cannot survive on its own. A product isn’t just a collection of features either, as it also includes the whole journey and experience, as well as other factors like getting people onto the product. However, a product will have more than one feature. A feature on its own will not deliver value to the customer, whilst the product will.
It is equally important to note that the user experience by itself is not a product, you can’t have a user experience without a set of features for the customer to use and interact with. UX is simply the way in which a customer interacts with and uses the product, so its how the product should be built and used. It isn’t something to be built in abstract.
Then how do projects fit into this?
A project is a well defined piece of scope to deliver. It could form a release of a product, for example the next version of an operating system, or a collection of features to release. However, it should be well-defined and have a definite end point. Products on the other hand, last as long as the customer need is relevant and being addressed. They also have different success criteria. A project succeeds if it is completed on time and on budget, however, a product is successful only if it delivers value to the customer. Products are essentially long-term and evolve. Projects are short-term and well defined ahead of time.
Putting it all together
What this all means is that a product is greater than the sum of its parts. Features and good UX can make a good product, but a great product comes from understanding your customer, how they are evolving and measuring where your successes and failures are.Read More From This Author
React Native Engineer (London)
Champion software quality and technical vision for AND and our clients, work on large-scale projects and help junior and mid developers grow in their roles.
Technologies you will be using
Tech Lead (Reading)
Bring your expert tech knowledge to the table to influence the direction of projects, whilst coaching and your team through engineering best practices.I'm Interested
DevOps Lead (Reading)
Bring your delivery expertise to the table, leading the pack as ambassador on operational requirements, influencing and continuous development.I'm Interested