When thinking about prioritisation for a new product. There are 5 assassins waiting to strike. They sit there, hidden in your backlog, undetected until the time is right and just when you think you're making progress, they make themselves known. In this blog we talk about the 5 assassins of product planning and strategies for how to combat them.
If you are expecting that data you’re planning to migrate from an old app is going to come without a fight, think again. The way you extract, transform and load the data can be extremely unpredictable.
It’s not just about moving data, but also about the data itself. If the data isn’t clean, in the right format and consistent you are likely to run into problems down the line.
Perhaps you’re not intending to move data at all but are planning to integrate with another product. Even if the API is fully documented, it doesn’t mean it will work exactly as written.
We need to understand and prove how our software is distributed, all the way through to live. There’s no value building software if it never sees a live environment.
Third parties have been known to make some pretty bold claims. Outsourcing seems like such a great idea – new relationships are particularly at risk of introducing dependencies that you can’t control which cause headaches down the line.
If you suspect any of these assassins are lurking in your product, my recommendation is that you prioritise a small, demonstrable, part of your product as soon as possible that tests any assumptions we might have. Then you have the most time available to react if something is unexpected.
What you're looking for is a tracer bullet style piece of work - a production quality piece of valuable work that proves an end-to-end system. It's all about cutting that initial feedback loop down to as small as possible.
Let's look at some examples:
- Data Migration - A script that loads one piece of data from the real source, transforms it into target format and saves it into your database.
- Data Quality - A script that pulls in 10 random records from source data and displays it on the screen for review by a human.
- Data Integration - Sending and receiving a request to an API for a single piece of typical data.
- Path-to-live - Take the phrase 'Hello World' through to a production environment and display it on a web page.
- Third Parties - Third parties are a little different, I would look to prioritise a feature which has a large amount of required feedback from the customer and I would want to see demonstrable releases to a production environment every week.
The above are only examples, I'm sure in your specific context you have particular needs that can't be addressed by generic content. So what's different for you? What assassins do you have?