Product development is an interesting activity. It involves a lot of challenges and lot of learnings. But over time, we get to learn a lot of crucial lessons. In this post, I am going to share some of my learnings based on my experience in Product Development.
- Go for an MVP rather than a full blown product
- A product might require lot of changes according to the changes in the market. Hence it is imperative that a product needs to be shipped as soon as possible to the customers to get their feedback. But how do we ship our product in 3 months when the actual development takes around 2 years. That’s when a Minimum Viable Product Strategy will help.
- Assess what the market requires and prioritize that over the internal product roadmap
- A lot of times, we have fancy features or features that provide extra punch to the product. Those can wait. What really needs to go to the market quicker are the features what the market really requires at present, solves the problems at present. It is like “A bird in hand is worth 2 in a bush”. Do not include features envisioned by us too early in the life cycle, they can wait until they are absolute killer features / selling points.
- If a product takes shape, increase the investments on the Product to take it to completion
- Ship in incremental chunks
- The architecture, the team, the process needs to be agile
- This means that we can adapt to any future changes in a much quicker time.
- Follow Agile Methodologies
- Agile methodologies put a lot of emphasis on the Customer who is the starting point of the product. Without customers, we would not be developing any product. Hence it is imperative we give that focus by following the Agile methodologies. Apart from being customer centric, it also puts a high emphasis on Quality Working software at regular intervals, Welcoming Change, Collaboration, Team morale, People, Continuous Learning, Evolutionary design and lot of cool stuffs that really help product development at a very good pace.
- Follow good engineering practices
- As the product evolves, it undergoes a lot of changes according to the feedback from the market. According to me, “The ability of the project team to add new features to the existing code, testing and deploying it in a quick manner will eventually determine the long term success of the project”. Instead of resisting those changes, the trick is to welcome those changes by having proper engineering practices in place that will aid these changes in lesser amount of time. Some examples of these engineering practices include Automated Unit Tests, Test Driven Development, Continuous Integration & Deployment, Automated Functional Tests, Automated Acceptance tests.
- Strike the balance between management expectations and quality of the process
- Management sometimes expect miracles, we can pull it off occasionally but not often. There is a tendency to sacrifice quality for faster release time. When that happens, it would be a short term measure. Although once in a while it may be needed based on the demands of the business. But it will affect the product quality in the long term and the ability to make changes in the product effectively.
- Don’t force Agile methodologies if the team is not ready
- For any Agile practitioner, it is easily understandable that Agile is not for everyone, it needs a good amount of maturity from the team itself as they are the cornerstone of the entire project. Give it a try, tailor it, try to make it work, but if it doesn’t work out don’t force it on the team. Go in incremental steps, try some Agile coaching, but don’t ever try to force it, it can turn out counterproductive.
What have you learnt from your product development experience that you are willing to share it with the audience? Please feel free to add your views. Comments/Critiques are also welcome. Thanks for reading.
A FREE guide for agile teams.
Are you running retrospectives regularly? Perhaps you run retrospectives once a week, or fortnightly. Do you feel like you could be getting more out of your retrospectives and fuelling continuous improvement in your teams? You may already find retrospectives valuable, but suspect there are ways of making them better.