10 tips for success in digital product delivery. Part 1: People
You’ve identified the right product. You’ve tackled the 4 big risks. Now you just need to build the thing. What could go wrong?Read more
This is the final post of our three-part series exploring the ‘hows’ and ‘whys’ behind building success in digital product delivery. In part one, we focused on people and what conditions they need to deliver success. In part two, we discussed what areas of the product you should focus on and when. It’s time to talk about the process of digital product delivery and share the final three tips. So, let’s take a look at how to structure your implementation to boost your team's chances of a successful outcome.
According to the Standish group, an astonishing 45% of features are never used when a product team takes a serial approach to requirements elicitation. In other words, if you try to define the entirety of your product before getting started, then you’re highly likely to create a product that will fail.
There is a natural inclination among business stakeholders to understand the full scope of the product they are agreeing to when they commit funds to a particular project. That mindset needs to be balanced with the fact that you’ll only learn whether or not your product is valuable when it's used in a real context – and by a real user. That’s why the concept of iterative development is so important: starting small allows you to learn quickly and avoid spending too much money creating a product that no one will use. As Yogi Berra said: “'It's tough to make predictions, especially about the future.”
Many companies take that first small step by building a “Minimum Viable Product”. At Somo, we take this one step further and create a “Minimum Loveable Product”; if the goal is to delight users, we need to aim higher than just creating a product that’s viable. By deeply understanding customer needs and working with stakeholders to prioritize key features, we quickly release a valuable product and enhance it based on customer feedback. This lightweight approach allows us to quickly gain insights into customer behavior and iterate rapidly to ensure maximum loveability.
Well written specifications are a developer’s best friend. They provide the details of a component’s boundaries (including the data and user interface), which removes the guesswork from a developer’s job, instructs the QA on how the product should behave, and provides a reference for any stakeholder interested in how the component works.
Knowledge evolves over time. That means specifications will quickly become out of date as edge cases are addressed and new features and functionality are added. If specifications are not updated, their benefits will quickly diminish and you’ll be left with a pile of stale documents that provide no real value to anyone. You’ll quickly run into a scenario where the only way to determine how the software works is to ask a developer to check the code.
What can be done to ensure specifications are kept up to date? The following scenarios are telltale signs that a specification needs to be updated:
A developer or QA has a question about the specification. This is a sign that the language in the specification needs to be updated to be more explicit about what the component should look like or what it should do.
A feature is being added or changed. This is a sign that the specification should be updated to account for the new feature or changed to reflect the feature change.
A bug is filed against the component. Of course, this will be highly dependent on the nature of the bug, but this is a sign that not all scenarios were covered by the specification and the documentation should be updated to account for the additional use case.
Keep an eye out for these triggers and don’t hesitate to update a specification when they arise. This quick time investment will save significant and prolonged heartburn in the long run.
Have you ever seen a digital project get torpedoed because of changing priorities, budget cuts, or other factors? This happens all too often and can be avoided, in part, by adopting and slightly altering one of the foundational principles of Agile: the primary measure of progress is working software in Production.
Features in a test environment provide no value to customers. The only way to measure the value of a software product is by releasing features into Production and evaluating the behavior of real users. While it’s tempting to try to perfect a product and create a rich feature set before launching, remember that the team’s efforts have little value until the product or feature is in the hands of users. And every day that passes without value being delivered to Production is a day that stakeholders cannot see the benefit of the product team. Is this unfair? Maybe. But perception is stronger than reality, and a surefire way to prevent any negative perceptions about the product and product team is to show true customer value.
An added benefit of this lens is that it keeps the product team focused on the goal line. It’s easy to feel like progress is being made because the team is demonstrating features in a test environment every sprint. Reiterating that the ultimate goal is to create value for users in Production will allow the team to enjoy making progress in a test environment but celebrate the creation of value for Production users.
Traditional “waterfall” style approaches to product delivery have been replaced by lean thinking – an approach that focuses on learning and iterating quickly. Ensure your product delivery processes are set up to embrace this new way of thinking, because good processes yield good results.
I hope you enjoyed these blog series! Use these tips to pave the way to successful product delivery and reap the rewards for years to come.