Introduction

I’ve seen a lot of product development processes over the years, and as with most things, it’s important to take what works for your organization, and leave what doesn’t work.  These processes go by different names, mainly various combinations of the words Product Development Lifecycle (PLC or PDLC).  There are also a common thread through most product development models, and this article assumes that the reader has a basic understanding of the general five steps of product development:

Great work has been done on fine-tuning the details of the PDLC, but it has always bothered me that there is not one universal model for software product development that fits two main criteria:

• Specific enough so that it gives real and practical guidance for product managers and organizations on how to design and develop good product.
• General enough so that it can be applied to all different types of software development methodologies (Agile, Waterfall, Spiral, etc.)

And that is what I set out to do in this article.

A universal model for software product development – first draft

So, here is what I have come up with so far.  I hope that this initial attempt at a universal model for software product development can generate some discussion on what works and what doesn’t, what’s missing, how it can be refined, etc.  Below the illustration I go into more detail on each aspect of the model (click to enlarge).

There are a few assumptions that are important to note about this model:

• Regardless of the development methodology, representatives from Product, Marketing, Business, Design, and Engineering should be involved to some extent in each step, all the way to the writing of the technical specifications, after which it largely becomes an Engineering and Product effort.
• Having said that, it is important for one person to own this process (i.e. be accountable for its success) from start to finish, and that person should be the Product Manager.  A good product manager is not a dictator.  He/she is a facilitator between all the different stakeholders in a product, and the really good ones are able to get through this model on time and on budget, every time and with as much consensus between groups as possible.
• This model is designed to work for any organizational structure, project size, and timeline.  If the project is large, more time can be spent on each step.  If the project has a tight timeline, it doesn’t mean that you will skip the “Iterate” part of “Design + Iterate.”  It just means that you will spend less time on it (more on that later).
• I highly recommend reading Adam Nash’s post entitled “Guide to Product Planning: Three Feature Buckets.”  He recommends that every feature release should have a combination of what he calls Customer requests, Metrics movers, and Customer delight.  I am in total agreement with him, and this is an important underlying assumption for this model to work effectively.

Detailed discussion of the different aspects of the model

Let me start by saying it is possible to write a separate blog post about each of the bullet points below.  My goal here is to be general and make one or two points about each aspect.  If there is interest I could expand further on any of the concepts in the model.  So with that said, let’s look at some definitions and implications of the model:

• The starting point – identifying needs.  At the beginning of any project (new or iterative), it is important to gather and synthesize input from three different sources:
  • User needs.  Everyone needs to have a good understand of the market, the target segments, and their behaviors and attitudes.  There’s not enough room to go into detail here, but it is important to look at four sources of user input: market research (segmentation, etc.), user experience research (usability studies, ethnographic explorations), site analytics (behavioral analysis), and customer support (call transcripts, interviews of CS reps, etc.).  Having this common understanding allows the organization to build products that matter to users.
  • Business needs.  User experience practitioners too often neglect the fact that well, your site has to make money!  Revenue goals are not a good excuse for bad design, and that attainable revenue goals are essential to push the organization to design good product.
  • Technology needs.  Engineering needs to be at the table from the start.  They know the limitations of the product, they know what needs to be fixed, they know where the architecture can improve.  Their up-front input is essential in good product development.
• Problem statement (Requirements).  I am indebted to Pragmatic Marketing, particularly a post entitled “On Reqs and Specs: The Roles and Behaviors for Effective Product Definition,” for the definitions I use for the three different documentation outcomes in this model: Requirements, Functional specifications, and Technical specifications.  The first outcome from the discussion and synthesis of needs is a common understanding of the problem statement you are trying to address, which takes the form of Requirements.   A requirement is simply a short statement of the problem, and Pragmatic Marketing recommends the following format:  “Our preference is the Requirements That Work format: [Persona] has [problem] with [frequency]. It forces product managers to explore the problem, not the solution, and helps the design team understand the context of the problem.”
• Diverging and converging design thinking. Once the problem has been defined and agreed upon, the team starts thinking about solutions.  There are three important aspects of this phase, which is often called Product Discovery:
  • Start with blue sky ideation (divergent thinking).  At this point, don’t limit solutions by what is technically or otherwise feasible.  Spend time dreaming about the product – this is where innovation happens!
  • Relentlessly prioritize (convergent thinking).  This is the part of the process where nonsensical ideas are thrown out, and the team consolidates around a few possible solutions to the problem that can be further explored.  Remember: there is no commitment to implementation or specific designs yet at this phase.
  • Apply the technology filter only after the ideation phase. I wanted to explicitly call out the roll of Engineering during the solution discovery phase.  It is a mistake to bring Engineering in too late in the process.  There is a very important technology filter that needs to be applied during prioritization.  What is technically feasible?  If something is currently not feasible, what would it cost to build the right architecture?  Those early inputs can save a lot of headache down the road.
• Functional specifications. The second output document from this model are the Functional specifications, which Joel Spolsky defines as follows: “A functional specification describes how a product will work entirely from the user’s perspective. It doesn’t care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on.” Note that we’re not talking about technical implementation yet, that comes later.
• Design and Iterate.  Everyone designs a product, but it is sad to see that when time/budget gets tight, iterating on it before it goes live is often the first part of the process to fly out the window.  It cannot be overstated how important it is to prototype and test your designs before they go live.  And not having time is really no excuse.  If you have no time, make a paper prototype and test it with three of your friends over coffee in the evening.  You’d be surprised how much value this can add.  Boxes and Arrows has a great article on prototyping and how to integrate it with your design process that’s well worth the read.
• Technical specifications. Only once you have a set of Functional specifications and a Prototype of some form (even if it is very low fidelity), it is time to work on implementation.  Quoting Joel Spolsky again, “A technical specification describes the internal implementation of the program. It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc.”
• Build and launch. If you’ve done the upfront work, this could actually be the easy part.  You have a set of requirements, a prototype, and a detailed set of specifications to work with, so now it’s time for the Engineers to work their magic and build the product.
• Assess.  The assessment phase is extremely important and often overlooked.  It is important to define your measures of success upfront, and then follow up to see if you’ve met those goals.  How do users respond to the product?  Are we meeting revenue/engagement goals?  Are there bugs that need to be fixed?  What can we learn from how users interact with the product to give us ideas for new products?  I’m also an advocate for using the same four sources of input we discussed earlier (market research, user experience research, site analytics, and customer support), as opposed to relying on only one methodology, like a 3-week A/B test.  More on the dangers of that in one of my earlier posts.

Implications and final thoughts

I think this is a decent first attempt at a universal model for product development that can be applied to any timeline or organization type, but it is far from perfect.  I hope that the product management community can come together and refine this so that we can end up with a credible, relevant, and useful model for building great product.

Eventually, I’d like us to build out this model so that it is more easily adjustable based on certain constraints that might exisit within a project, such as budget, time, development methodology, and team size.  But let’s see if this one passes the smell test first…