Product Development Types: What Challenges to Expect in Each Case?

Not all types of product development are the same.  The most three distinct types are:

• Internal Product development, where
  • Users/Customers are internal
  • Product Owner is internal, playing the role of a conduit between Users and Technology
  • Dev/Technology/IT is internal, mainly dealing with Product Owner (and her team)
• Outsourced Product (“Project”) development, where
  • Users/Customers are internal
  • Product Owner/Lead User is internal, playing the role of a conduit between internal Users and external Technology vendors
  • Technology is external, represented by vendor-companies
• External Product Development, where
  • Real (paying) Customers are external
  • Product Owner (classic Product Management/Business Unit) is internal and facing external Customer
  • Technology/R&D/Development is internal and interacts only with Product Owner

While these classifications may seem to be obvious, there are some important “nuances” that are often being overlooked.  Awareness of these nuances could be important for making product development practices less vulnerable.

Here are some potential pitfalls to look out for, with each type of product development:

(Note: This post does not provide any recommendations on how to avoid/reduce pitfalls.  Some suggestions might be covered in future publications.)

Internal Product development

• Fake Product Owners (delegates, proxies, surrogates) that lack either authority, or vision/breath of product knowledge, or both
• Artificial “internal contracts” between various company units, secondary to organization design. These, are often driven by internal competition, ineffective external motivation, subjective monetary incentives and bonuses
• Technology is too remote from real customers, does not deal with them directly and has to go through additional organizational layers, units, groups, roles (even to get to  internal Product Owners)
• Excessive amount of processes, tools, metrics/KPIs and reports that are used as mechanisms for measuring business value delivered and levels of customer satisfaction.  This is because of absence of real, short-loop customer feedback.

Outsourced Product (“Project”) development

• Low mutual trust (both, client and outsourcing company). Product development process is “wrapped” into artificial projects and portfolios, typically, with fixed scope, timeline and budget.  Customer-vendor relationships are very contractual, with legal binders.  While there are much more effective agile contracts that exist today, they are rarely used, because of lack of ability, by either side, to execute them.
• Documentation is voluminous and is at expense of collaboration and transparency. Approvals and sign offs are mandatory and are usually accompanied by rigid legal processes
• Unfit vendors: many companies still rely on vendors, with whom they have been dealing historically (via vendor management system), instead of turning to a market place, every time there is a new need,  and searching for best candidates. Preferred vendors feel safe and comfortable, and with such “monopoly” in space, they have low, if any, desire to strive towards improving technical skills, adopting new technologies, etc.   Also, nothing prevents such “preferred” vendors from making unsubstantiated claims about their experience with agile product development: rarely cases studies or references from other clients are requested.  Fixed contracts just make things worse.

External Product Development

This product development type is probably the best candidate for agile approach: customers are real, real money exchanges hands, competition is real and often strong, fast market changes require product companies to be nimble, light-footed and fast-responding.  However, there are still some challenges here.

Specifically, the communication channel called “Clarifications” (between Technology and external Customer) that is crucial in agile development (e.g. Scrum) is usually weak or does not exist at all.  Due to geographic distribution, legal contracts and compliance issues, it is challenging to co-locate real customers and developers and have them directly engage with each other.

Since everything flows through Product Management /Marketing/Business internal organizational layer, technologists get their information second-hand.  This also leads to producing additional overhead (processes, documentation, and approvals) by a product development company:  multiple external communication channels and competing priorities (different customers) that must be collected/filtered/prioritized and then single-threaded to technology.  To complete this job, internal Product Owner will require help.  This is how internal Business Units grow thick and as this happens more waste/overhead is introduced to a system.