Rajaraman Raghuraman

About Rajaraman Raghuraman

Rajaraman Raghuraman is a highly passionate software craftsman with 8+ years of experience in the IT industry. He is also the owner of AgileDevTest Blog (http://agiledevtest.blogspot.com) and author of an Ebook "Programmer's Motivation for Beginners" which is available at http://programmersmotivation.com.

Lessons Learnt in Product Development

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
    • Typically things start small and then the product gains momentum in terms of popularity or demand and is seen as a value proposition.  Then it is time to increase the investments in the product to make it more robust, stable and to deliver it fast to the market.
  • 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.
 

Related Whitepaper:

The Retrospective Handbook

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.

Get it Now!  

Leave a Reply


three + = 11



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books