Throughout my career, I’ve had a number of opportunities to be involved with (or own) software product development. This includes shrink-wrapped (video games), frameworks (for enterprise development), enterprise COTs (supply chain) and CRM (customer integration, digital integration and vertically tailored solutions).

Recently I was working with a potential client, and they are looking to build out a product capability, which brought up a really great discussion on methodology for product development vs. regular software development. I thought it would be a good idea to spend a bit of time thinking about it and writing up some of the similarities, differences and generally good practices required to be successful at product development (many of which I learned by doing the opposite and living with the failed consequences).

Just a few of the thoughts that come to mind:

• Methodology: Software development follows an SDLC (software development life-cycle) while product developments follows a PDLC (product development life-cycle). This is a pretty significant difference because the life of each is way different, this is primarily due to the fact that software is typically built once, deployed once and maintained once. Products are built to be sustained, deployed to many customers and maintained across various deployments. Just as there are many SDLCs, there are also many PDLCs. I think the single most critical part for SDLC is how requirements are a captured and implemented, and I think the single most critical part for PDLC is similar – making sure you really understand the core of what problem the product is being built to address. Especially with products, it’s easy to want to implement feature and feature. But if you don’t get the core right, it won’t be a success.
• Requirements: Both product development and software development starts by having good requirements. And one of the most critical aspects to getting good requirements is by going directly to the users. One thing that does often distinguish product development is that you are solving a general problem instead of a specific one. This often leads to development teams “making up” requirements based on what they believe future customers will want. This is a huge mistake. (And one that can often occur building software too.) If a user hasn’t asked for it, don’t build it! If you think they might like it, ask them!
• Financials: Both development efforts should take a business case oriented view. Financially, you are making an investment, and you need to make sure that the ROI is there. For product development, this should be much more extensive because the investments are typically higher, and you need to make sure you are really analyzing the marketplace and potential uses. A good PDLC puts this front and center, but it’s important to do this more than just at the start – you need to continually look at the market and make sure that you have a viable product. Of course, one really big challenge is when you are successful making sure that you continue to innovate.
• Testing:  proper testing is important for SDLC, but, frankly, you have a bit more wiggle room. In PDLC, testing is critical not just to make sure your product is low on defects, but it’s also a continued validation of the value of the product you are building. Don’t think of testing as just quality assurance; treat it like market testing as part of the PDLC.

I know there are many other aspects to software development vs. product development that I haven’t brought up, but I think this is a good start to the conversation.