Product Development is Really Quite Simple

Product development is really quite simple.  All you must do is:

1. Specify a problem;
2. Develop a solution that addresses the problem.

So, why are their so many failed attempts at delivering high quality products that are valued by the customer and pay off for the developer?  Like many things while it looks simple at 100,000 feet, the devil is in the details.

There are many things that affect how you think about product development.  These include:

• The size of the product development effort. This affects the approach and the timeline.  And trust me:  1) the approach that works on a large product development effort doesn’t on a small one; 2) if you get the timeline wrong, which you will if you don’t understand the size and scope of your effort, heads will roll;
• The complexity of the product, which can be inherently complicated, like an accounting system or may have components in several different mediums (i.e. software, hardware, process, etc.) or across several functional areas (like an ERP which includes components that integrate to provide an order to cash processing capability) that all must integrate seamlessly;
• How the product fits into the product portfolio, i.e. is it a standalone offering or part of an integrated (sometimes called a platform) product set;
• The accessibility of the customer set. This effects your ability to interact, observe and extract an understand of what the customer needs.  It is nearly impossible to properly serve the customer from a distance;
• The maturity of the market for the product. This affects decisions regarding the approach to product development.  One question that often gets asked is: Does one make incremental changes or try to change the game.  Sometimes the right answer is not obvious—at least to the people tasked with making it.

So, the first thing that you must consider is the context in which the product is being developed.  A significant addition to an already substantial existing product or even more extreme an addition to an existing product set (i.e. platform) is a complex endeavor because is checks many of the items in the aforementioned list.  Size and complexity matter because the bigger the effort the more people involved and the more people who are involved, the more overhead in keeping people informed and headed in the same direction. 

Further, the more pieces of the product puzzle that must fit seamlessly together, the more coordination that is necessary to ensure that the smoothly mesh into a coherent whole.  It took Microsoft some time to get the Office products to be what could reasonably be called a platform.  To achieve the benefits of being part of an integrated platform, each of the components (Word, Excel, PowerPoint, etc.) needed consistent menus and an ability to seamlessly share and exchange content.  They have mostly achieved their goal, but even with all that effort there are still holes.  For instance, there is no feature that allows one to manage the customization (setting parameters like how often it autosaves, your user name/initials and proofing options) information once and have it propagated to all of the Office applications.

Even when you are staring with a clean slate product design, you need to consider the future.  What features will you add now and what features in the future.  And, how do you ensure (both technically and functionally) that future features, and there are always new features that later need to be added, can be easily (in a way that is both useable and maintainable) and economically integrated into the whole.

While context setting is important (it sets the requirements for how rigorous the process is going to be and how many people will likely need to be included in the effort—defining both the process and important inputs to the estimating model, i.e. the bigger the project, the more overhead per productive hour spent defining the project), there are certain functions that are relatively invariant.  They were mentioned at the beginning of this post:  1) specifying the problem you are looking to address; and 2) solution development.

I like to think about these two functions as being part of a single process where several techniques are used to consistently get the best results:

• The first and most important is basic Consulting 101. But, calling it “Consulting 101” doesn’t do it justice.  It is really is a 400 and 500 level (at UChicago those were, in my day, the PhD level classes) course.  Doing a good job defining a problem requires a person who is a good analyst, has broad experience across many domains and is skilled in active listening.  Someone who knows when not to ask a question, but to observe the processes and listen as their clients explain what they do.  You can’t go into these situations with preconceived notions.  You need to observe and listen.

I contrast this to consultants who ask: “What is wrong or missing?”  They generally get a list of things that are top-of-mind (things that have bothered the customer in the last 24 hours) and not get valuable insights into what is really needed by the customer.  What they get is a shallow, narrow understanding of the problem.  In my consulting days, we used to call this kind of analysis of a problem “order taking”.  It was practiced by the less experienced consultants.  It often made clients happy (they asked for things and then got them), made a lot of work for the consultant, but didn’t get to the heart of what the client needed.

Let me give you an example of the process done right.  When Pat Allin and I started looking at the opportunity that would become Textura, we spent considerable time with all the players in the construction process.  This included the General Contractors, the Subcontractors, the Bankers, the Title Companies, the Lawyers, etc.  We observed (by doing things like riding along with General Contractors as they went about their business) a badly broken payment process.  It was as obvious to us as it wasn’t to the aforementioned players.  Had we asked them what was wrong with their business, it is very unlikely we would have specified a solution to a broken payment process (because the players didn’t even recognize it as broken) and the dramatic improvements in efficiency would never have happened.

I have a similar issue with using surveys.  They are blunt instruments that tend to elicit narrowly focused responses that rarely have the depth and breadth of observations made by a top-notch consultant.  That said, surveys do have their place and help to tune both service delivery (a different topic altogether) and product plans that have been developed using a consulting approach to understand the “problem”.

• The product design function builds on the previously described problem definition work. And, before we get into product design a few more comments about problem definition:

1. You should get as much of the problem definition work done as is practical before you start product design. I know that iterative methodologies are all the rage, but it really helps to understand the (whole) problem before trying to solve it; and
2. You are likely to have more problem than you are going to be able to solve in each step of the product lifecycle. If you don’t, the product probably doesn’t have legs and will not take you where you need to go in terms of longevity and return on investment.

So, be aggressive in pushing parts of the problem out to future iterations of the product and focus on making each generation of the product something that you can deliver on time and that will provide a well-defined set of features that make sense to the customer and can be delivered in a reasonable amount of time.  Don’t make the mistake of trying to fit every idea you collect into the current iteration of your product.  There is a time and a place for each feature, be patient.  To that point, one of Pat’s early Textura related ideas, a real whale, had to wait 10 years to be implemented (there were many pieces that had to be in place before it could be implemented successfully), but now that it has been, it is proving to be a real game changer.

That said, solutions to worthwhile (in terms potential ROI and value to the customer) problems take time and effort and a broad perspective.  I would therefore suggest a diverse (training, experience, interests, viewpoints and cultural backgrounds) team is essential to good results. 

The tension generated by diverse points of view helps to forge a better product.  The act of team members with different perspectives talking things through and working towards a single solution often brings ideas to the table that neither party individually might have suggested. 

For instance, Pat and I both saw the need for improvements in the construction payment process, but it was my suggestion that we make Textura a cloud solution (which was a new thing, for financial processing, in 2002) that made the solution practical for a client base that wasn’t likely to invest in the hardware necessary to process on-site.  It also prompted Pat to realize that the cloud implementation meant that subcontractors only need to sign up once and could use that profile to collaborate with multiple general contractors.

Let me be clear, diversity is very frustrating to me.  I will often show a little too much of my frustration (it isn’t always easy listening to other people’s ideas, especially when they are different than yours) during meetings, but like exercise, diversity might sometimes be a lot of work (even painful), it really pays off in the long run.

So, let me amend my opening statement: Product development is not really all that simple.  It takes people who have training and experience and a diverse set of inputs to consistently produce good outcomes.