The following post was inspired by a question on Quora. The primary question was "How do you successfully launch a product?" In addition, "What factors will help you take your product to the broadest audience?"

Whenever I hear the phrase "launch a product," I calibrate my orientation by examining the perspective of the individual involved. 

ROLE = TYPICAL MARKETER

If the role of the individual is a typical marketer or a communications specialist or a social media advocate, then expect an explicit list. The list provided by Balaji Viswanathan is consistent with this perspective. Such lists have the appearance of a 'best practice' and are easy to edit. Such lists are process-centric. Responsibilities can be delegated according to roles with a consideration of headcount in an organization. 

Too often, I have noticed that the list is held in higher regard then the individuals contributing to the effort. Too often, the individual contributors are considered plug-and-play resources that have a minimal ability to shape new product development. Too often, the individual contributors are expected to follow an explicit process and do what is expected.

It is my experience that such an approach contributes the failure rate of new product development efforts. Such an approach tends to produce mediocrity. Such an approach tends to lack the agility to adapt to emergent conditions. 

ROLE = TYPICAL ENGINEER

If the role of the individual is a typical engineer or programmer, they may hope that some other specialist provides a list of requirements and project constraints. Under such conditions, they can do what they do well - solve problems. 

Typically, this is a sub-optimized approach. There is always a question about requirements. Have they been validated? Will they be valid in 6-12 months when the project is ready for launch? Should the requirements have been labeled 'hypotheses?' How significant were the framing errors associated with the requirements? What framing errors have cascaded through the project constraints to become milestones?

When an intelligent engineer or programmer lacks a holistic involvement with the project, it is likely that they will not provide the most value to the project and contribute in the ways that are most likely to result in success. 

ROLE = TYPICAL MANAGER

Some identify their primary role as managers. They may augment their title with words such as 'section,' 'product,' or 'project' manager. The least passionate of these see their role as 'herding cats' and enforcers of the schedule. Often they work in the shadow of an iron triangle. Some adopt newer titles such as 'Product Owner' or 'Scrum Master.' 

Too many are managers and not leaders. Too many are enforcers and not enablers.

ROLE = TYPICAL FRAMEWORK DEVOTEE

Another common role is the evangelist for the latest framework or method. They advocate for new jargon and processes associated with their favorite celebrities. Examples include those that are exuberant about Agile, Scrum, Kanban, Lean, Lean Startup, or INSERT_YOUR_FAVORITE. 

Too often, such efforts are what Alistair Cockburn refers to as Shu-level. The understanding barely goes beyond a limited vocabulary. The commitments by the other individual contributors are modest. Adopting a new methodology or framework is likely to need more than 18 months to show significant impacts. 

ROLE = NEW PRODUCT DEVELOPER

When Clinton Keith described this for the context of game development, he wrote:

 “For a cross-discipline team that is measured by value added to a working game, the role of an artist shifts to that of a ‘game developer’ who specializes in art. An artist doesn't simply create an asset for someone else to put in the game and make fun.  The artist participates in the creation of an experience, where art has an equal value. By having a voice in the discussion about what is being created, the artist elevates the value of what they create and minimizes the cost of creating it.” -  from the book "Agile Game Development with Scrum" by Clinton Keith (@ClintonKeith) page 227. Published in 2010.

This framing facilitates extraordinary cooperation and collaboration. The contributions can transition from following an explicit set of directives to embracing implicit cooperation and collaboration. In this context, implicit is used to convey a meaning of closely connected, joined, interwoven, and intertwined.

This context enables individual contributors to thrive in a complex adaptive system. Such systems co-evolve with the environment, have interacting agents, and emergent properties. The system impacts the agents. The agents impact the system. They have the potential to be self-organizing. There is not a single point of control.

In a complex adaptive system, the system and the agents co-evolve. We manage the present and evolve to an uncertain future. In these systems, we manage the boundaries and the probes. In such systems, you can do better with less. In these types of systems, we strive to manage the network relationships. 

Weak signal detection is very important in complex adaptive systems. They are not causal. They may be pre-disposed but one will not get 100% predictive capacity.

Complex Adaptive Systems are nonlinear. A small change can have a huge outcome.

In this role, an individual contributor does not identify themselves with a 'front end of innovation' specialist, R&D engineer, or marketing communications generalist with special social media capabilities.

LAUNCH FROM ANOTHER PERSPECTIVE

I prefer to view launch in terms of validation. 

• How did my efforts contribute to the value assigned by the customer?
• How much of my efforts were directed by unvalidated inputs?
• Am I better equipped for the next project?
• How much clean-up (re-work) will be necessary after the product is used by a large number of customers?

SATISFACTION

I expect a few baseline items during any project. I expect to receive fair compensation for my work. I expect to be treated respectfully.

Satisfaction requires more than that. 

The Principle of Obliquity applies. Some objectives (such as a successful product launch) are best pursued indirectly. 

Barry Boehm stated that the most important factor regarding productivity was personal/team capability. (From the cover of his book, Software Engineering Economics)

 Several suggestions that will position your efforts for a more successful launch:

• Populate your development environment with individual contributors that are pre-disposed to embracing their role as a new product developer who specializes in X.
• Emphasize a holistic approach. Minimize the perpetuation of independent silos of expertise that are disconnected from contact with potential customers.
• Encourage autonomy, mastery, and purpose for individual contributors (for more information, see Dan Pink's book - Drive)  
• Refine Schwerpunkt - a concept that provides focus, direction, an actionable guidance to the operation
• Design the environment to maximize the potential for the insights of individual contributors to impact the vision of the development effort
• Design your development effort as a network where individuals can enter and leave the effort as needed while ensuring the effectiveness of their contribution.  Minimize the command-and-control mentality that pretends that all the contributors are listed on your internal organization chart and subject to annual performance reviews.
• Embrace Alistair Cockburn's concept of development as a 'cooperative game.' 

SUMMARY

At the end of a project, I want to do more than confirm that I followed someone’s explicit list and met each milestone.

To maximize the potential for a successful launch, strive to ensure that the development environment is awesome for the network of individuals that have an implicit sense of how their contributions impact the effort. When the project is coming to completion, individual contributors should feel that their time was well spent, they advanced their skills, they made some valuable acquaintances, and that they are better prepared for success on the next project. A successful product launch is best pursued indirectly.