Having worked in successful and unsuccessful digital product-based companies, I have seen digital product development tactics that work and learned a lot from watching others fail. Pondering my experiences and also reviewing the reflections of seasoned experts like Neha Monga and Dave Wascha, I have compiled the following list of product development tactics for digital products.
What are some tactics for successful digital product development?:
- Launch Products Incrementally
- Launch Updates, Releases and Products Often
- Learn from Your Product Launches
- Learn from Your Competition's Product Launches
- One-way vs Two-way Door Decisions
- Set SKID Metrics: Scale-up, Keep, Iterate and Destroy
- Always Have a Launch Plan
Digital products are different from physical products. We expect frequent updates, feature releases and a higher level of engagement from those building/supporting the digital product. Even if your company sells physical boxes, they still need a digital presence and complementary digital products. So let's dive deeper into some useful tactics for digital product development.
1. Launch Products Incrementally
You have an amazing vision of what the next killer digital product is, but if it takes five years to launch, then your probability of success dimish rapidly. For a start, you will need to find extremely patient investors with deep pockets. In the meantime, your competitors could beat you to market, and you are not even sure if the product will succeed!
It's great that you have a strong vision of where you want to go, you can now work backwards and figure out what you need to do to get there and what you could quickly deliver that gets you closer to your goal. Each step you take will help resolve some high-risk hypothesis so that the further you go, the more confident you can be about your vision, which has probably been tweaked based on what you have learned.
The sooner and cheaper you can mitigate risk, the more likely you will be to succeed because you will be able to apply more of your resources to activities that have a high chance of succeeding. A big challenge for companies is to get the minimum in MVP (Minimum Viable Product) small enough. If you can operate the business with spreadsheets and phone, do that before spending millions on developing software. Software that gets turned off because it doesn't solve the customer's problem!
The MVP needs to answer a question, and once you have decided what question it needs to solve, then you can mercilessly cut back the MVP back till all it does is answer that question. If you try and cram too much into an MVP and it takes two years to launch, then you are back to square one.
If your MVP ends up only being a webpage with a form backed by a team of people who will manually process the request, that is FINE! It is cheap and easy to change the webpage, modify the form, refine your processes or throw it all out and try another idea.
Once you have proven the MVP is a success, then you can confidently spend some more resources delivering the next increment and answer another question etc.
2. Launch Updates, Releases and Products Often
Now that you have split your digital product into lots of small incremental launches that are cheap and quick to deliver, you can launch frequently and regularly. For digital products, customers expect frequent updates, new feature releases and related product launches.
The more you launch, the better you get at launching. You get better at not just planning, executing and learning from a launch, you also get better at dealing with issues when, not if, things go wrong. If you can learn from your mistakes, get good at limiting the effects of failure as well as get fast at resolving issues you will run rings around your competitors, or at least keep up with them.
In the digital product space, to be able to do frequent launches, you need close collaboration between the tech team, operations and business stakeholders. You all need to collaborate to work out what to develop next, how to build it good enough, and how to support it. If the feature/product compelling solves a problem for customers, construction and delivery are flawless, but the company drowns from all the back office work, then that limits scalability and future growth.
Building a tech capability that allows for rapid and frequent releases can be expensive and complicated. The tech team needs to build platforms, tools and processes for things like:
- Source code management
- Build and deployment pipelines
- Automatically scaling infrastructure
- Extensive system and functional monitoring and logging
- Incremental release capabilities
- Reliable rollback mechanisms
However, like the investment in development, marketing and operations need to be done incrementally with each release, so does the investment technology. As you gain confidence in the product with each successful launch and the customer base grows, then progressively increasing the complexity and maturity of the technology capability can occur.
3. Learn from Your Product Launches
We can interview customers, collect data and make some educated guesses about how our customers will react to the product. But we won't know what they think about the product until we put it in front of them. We can then see if they use the new product, do they use the new feature the way we intended and are they willing to pay for it.
Since we now release new features and products regularly, we have lots of opportunities to learn from our customers and refine our mental model who they are and how we can help them. To find out what our customers think we can:
- use analytics programs like Google Analytics and Clicktale to see their behaviour
- email or discuss the product directly with a sample set of users.
- read comments and reviews on social media
- look at the numbers
"We thought they would love the new feature, but on Twitter and Facebook, they are constantly complaining about it."
"Since we changed the shopping cart layout, we have seen an increase in average customer spend of over 10%!"
4. Learn from Your Competition's Product Launches
If there are competitors with similar digital products on the market, this is not necessarily a bad thing. We all have different idea and opinions so your competitor will try things that you haven't. As they experiment, you will also be able to observe. You won't have access to their internal metrics, but you can trawl social media and review sites to see what their customers thought.
When a competitor releases a new feature, you can review and decide:
- it was a bad idea, let's not do that with our product
- it was a solid idea but poorly executed, let's review internally
- it was a solid idea and well-executed but not appropriate for their customer demographic or ill-timed, let's examine if would work in our product or related product.
- it was a solid idea and well-executed and well-received. Do we need to implement a version to stay competitive?
Every launch done by your competitor is an opportunity for you to learn something about your market. They spend all the money and resources developing, marketing and delivering a new feature. Then you get to learn from their success/failure and continue from where they left off.
5. One-way vs Two-way Door Decisions
Two-way door decisions are reversible decisions. If a new feature is very unpopular or impacts the business negatively, then we can roll it back. The work to rollback a feature isn't only technical. Do we need to inform the customers and if so, how? Do we need to work with suppliers or vendors who may have built capabilities to service our new product?
One-way door decisions are decisions that are either not reversible or too expensive/difficult to change. An example, which is hopefully not applicable to you, is a release date that is locked in because "We have already spent a fortune on marketing". Selling a house, quitting a job and an international release of a physical product are also examples of one-way door decisions.
In the digital product space, we should be able to ensure most of our decisions are two-way rather than one-way:
- Make sure the feature can technically be rolled back
- Ensure marketing and customer service ready for a rollback
- Soft launch products before investing in marketing
- Frame pricing of the product so it can change, i.e. "Introductory price for a limited time only."
6. Set SKID Metrics: Scale-up, Keep, Iterate and Destroy
Every line of code that exists in production posses risk to the business. It makes the system harder to maintain (more complexity) and increases the number of attack vectors for hackers. So if the code is not adding any benefit to the business, it needs to be removed.
Conversely, if the new feature/product is popular, then we may need to allocate more resources or work on creating more content. Neha Monga described how a game she worked on took off, and she had to get designers to develop more levels quickly.
| Metric Level | Notes | Example Metric | Example Actions |
|---|---|---|---|
| Scale-up | We need to get some more resources on to continue to scale smoothly |
over 100 orders a day | Upgrade DB instance and organise two more customer service reps to field calls |
| Keep | Thank the team and relax |
over 70 orders a day | |
| Iterate | The product might still be good, but we need to tweak it |
over 40 order a day | Work with team on delivering another iteration of the product |
| Destroy | The product isn't a success |
40 orders a day or less | Rollback the product and, with the team, work out what you learned |
The SKID metrics and levels must be decided BEFORE launch! Having agreed SKID metrics before launch helps to formulate a better launch plan and makes it much easier to either get more resources allocated:
"We already agreed that if we had more than 100 orders a day, we would have the headcount for two more people in the Customer Service team."
or shut down the product:
"We agreed that if we only average 40 orders a day, we would roll it back and work on delivering product B. We are only averaging 25 orders a day."
7. Always Have a Launch Plan
A launch plan helps you sort out what needs to happen before, during and after launch. You should know what you want to learn from the product launch and have the SKID metrics in place.
A deployment should have:
- Entry Criteria: What needs to be in place before we can start launch.
- Exit Criteria: In what state do we need to be for us to say the launch is complete.
- Stop Criteria: If any of the following happens, we stop the launch and rollback.
The criteria help us generate checklists, which then help us outline activities. For example, our Entry Criteria may include:
- The customer service team is aware of the launch and is ready to field queries.
- Relevant members of the development team are available during the launch.
- All automated tests are passing and there are no unresolved critical issues.
- Required metrics are collected, are accurate and are reported.
Exit Criteria may include:
- No failures or issues have been reported post-deployment for 2 hours.
- A post-launch debrief has been scheduled for the next day.
- A SKID review meeting has been scheduled in seven days.
Stop Criteria may include:
- Critical issue reported during deployment.
- Deployment couldn't be done within the launch window three-hour launch window.
Related Questions
What is the difference between product strategy and product development? The product strategy outlines to stakeholders how the product aligns with the company's business strategy. It also discusses what needs to be done other than developing the product, i.e. requirements and impacts on sales and marketing teams. Product development refers to all the activities that take the product from concept to market.
What are the objectives of product development? The core objective of product development is to develop a product that solves a problem for customers. The product needs to be delivered at a competitive price point and of sufficient quality, that a customer is willing to pay for it. The price is relative to the importance of the problem it solves.
