Products are a bunch of ideas concertized by a bunch of builders and forgers, its life cycle is very simple, yet very difficult to understand sometimes and is very tempting to commit mistakes throughout the whole process.
It all starts with a vision, this is what a product genesis should sound like, then with that vision comes refinement, iterations and improvements. There are various product development methodologies and principles, but for now i will only focus on Agile Product Development.
The Vision
I chose to start with this, because it represents the soul of the product, without a vision, you can’t persist long enough to ship, to sell it, to even convince people to work with you and finally to give yourself the sufficient motivation to continue doing what you are doing. The vision is very important, it is the abstract of every product and shall always be the starting and most important point of each product development cycle.
The vision must be clear, free of ambiguous terms and achievable, the more ambitious the vision the better it is, but a balance between ambitious and achievable is key to success.
Generating Ideas
The second most important factor for success is knowing how to gather ideas, there are a various number of ways to do so (e.g: brainstorming). You can’t forget that your product must be used by the target user, and in order to do so, you must do it with them. Involving your target user in the product construction phase, is important, as it minimizes risks and keeps you from drifting away from your goal “Have a usable product”.
Organizing Ideas
I guess a messy pile of ideas, is not something you can explain to your peers nor the client, sometimes it is even impossible to explain to yourself. I think organization is important, here were an agile term comes in place “Product Backlog”, it is a collection of items that contains ideas and tasks prioritized in order to be easily planned. What a product backlog should contain is pictured in the figure below.
There is an abbreviation that combines similar characteristics of good product backlogs. This is DEEP:
- Detailed appropriately
- Emergent
- Estimated
- Prioritized
Prioritizing
The most important thing to note is priority, despite being an easy to understand yet not everyone understands it correctly. The most common mistake is “everything is prioritized”. This is very unhealthy and sometimes can kill the product. The term priority induces uniqueness in order, nothing can be executed in the same time. Estimate your backlog as if there is only one execution member, multi-tasking and scheduling is something else to handle in the product execution phase. The thing is, most product developers and owners, think everything is priority because the client said so, while in the reality the client sometimes doesn’t understand what a priority is and must be asked further to get more details. I do acknowledge that sometimes two features can have an equal priority but if we consider the impact, the time to implement, the resources, the cost… we will definitely come up with a different priority score. So i think that it is lazy to accept it as it is, and i guess that we should dig a little bit deeper.
Technical Priority
Technical priority is looking at items dependency, sometimes implementing a feature before another would make us more efficient. Here comes the technical insight, it is meant to make the backlog planing closer to the perfect plan.
Prioritization Techniques
Popular product backlog prioritization techniques help product owners in defining what items the team should work on next.
- Kano Model
- Opportunity Scoring
- MoSCoW Technique
- ICE Scoring Method
- Story Mapping
I will spare the detail for you to find in this article.
Product Backlog Refinement
A backlog item, should be refined from time to time, During Product Backlog Refinement, items are reviewed and revised. However, the Product Backlog can be updated at any time by the Product Owner or at the Product Owner’s discretion. PBR is a collaborative discussion process to confirm whether the backlog is ready for the next sprint.
The goal of Product Backlog refinement is to work with the Scrum Team and stakeholders (when relevant), to get Product Backlog items in a ‘ready state’. What does this mean? This basically means that the development team has the idea that an item is:
- Clear enough, so they understand what stakeholders are asking for and why they are asking for it.
- Small enough, so the items should be small enough to get done within a sprint (typically a few days of work) to comply with the definition of done.
Product Roadmap
A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time. A product roadmap communicates the why and what behind what you’re building. A roadmap is a guiding strategic document as well as a plan for executing the product strategy.
Mistakes to avoid
- Settling for a confusing backlog item.
- Preparing the sprint backlog in the last minute.
- Ignoring the technical backlog items.
- Assuming that some work can be done without passing by the product backlog.
- Ignoring the guidelines of the methodology you are following.
- Being lazy.
This blog was previously published on Medium.
