OpLaunch helps new product developers thrive by improving their capability to synthesize and exercise better development options. This maximizes a new product development network's capability for self-correcting focus and direction as they develop multiple ways to succeed.
Posts and podcasts produced by Mark A Hart, NPDP and founder of OpLaunch.
When I see explanations of product development failure that blame others, I try to look beyond the regrettable outcome of the past project. I delight in finding clues about the likely outcome of the next project.
The counterweight to a perceived lack of 'management understanding and support'
One of the common factors cited by individual contributors when projects have failed is the lack of "management understanding and support." That is regrettable.
What about the next project? What can you do to shape future projects for a more favorable assessment?
Here is some vital background:
Recognize that managers don't value your burn down charts, story points, standup meetings, or most of the agile rituals that are practices of an Agile development team. They are artifacts of your process. They are proxies for value.
Most managers are not going to be telling their manager friends about your agile artifacts. There will not be a favorable discussion about your agile process at their home or at the gym.
Most managers tend to value their favorite metrics. These tend to be the metrics valued by MBAs and accountants and sales managers and business development executives. Some of these may be called vanity metrics.
Asking for more "understanding and support" is not going to move the needle. The same is true for most discussions about improving company culture. Don't waste your time asking for more respect for your dogma. Promises relating to these items are transitory.
Debates about "when is the product going to be ready" and "fast-tracking the project" and "delegating responsibilities" take up a lot of time and don't produce much value.
The appropriate goals are to find the mutual items of value and deliver value.
Here are a few suggestions to shape the way managers behave:
Discover the language the resonates with managers and translate your conversations to use the appropriate management jargon when your are in the management boardroom. Since the project exists to provide value to some customer segment, encourage discussions that incorporate value related to customers which results in aggregate metrics like the quarterly and annual numbers that drive manager’s behavior.
If there is a request for some report or attendance at a long meeting that is not going to have a favorable impact on delivering value, challenge it. Ask for clarification. Recognize the detrimental results of interruptions and take active measures to minimize intrusions from anyone not adding value to the project.
Here are a few suggestions for individual contributors:
Minimize the time you spend complaining about a lack of management understanding and support.
Invest more time in becoming a better developer. Become faster and better at recognizing what is valuable to the project. Invest in improving the effectiveness of cooperation and collaboration with others contributing to the value of the project. Invest in ways to reduce the time it takes for a new developer to be an effective and efficient contributor.
Insist on the time you need for uninterrupted concentration for certain types of work.
Invest to make the next project better than the current one.
Do NOT babble about being 'more agile.'
Insist on disintermediation. Let everyone contributing to the development effort be able to see how their activity relates to value. Don't acquiesce. Do not accept an assignment if the person delegating it to you can not explain how it will add value to the project.
Find mentors and peers that will monitor your progress to become more awesome as a valuable, motivated development professional.
Strive to be more awesome
Produce recognizable value because when you do that, you will be recognized as a person that everyone wants to be on their next project team. Instead of trying to change the management culture directly, become a more awesome developer. You will be a happier developer.
In most new product development efforts, a designer’s goal is to reduce friction and promote flow. This also applies when designing web pages or when building an online shopping cart.
Most Designers try to make things as simple as possible for the intended user.
According to Burka and Gillis, “Much of the fun in a game involves solving puzzles and learning how to achieve objectives more efficiently. So you actually want to learn how to do things more efficiently.” They add, “There is a fine line between what is challenging and what is frustrating.”
A great game has challenges that a motivated player can master.
Burka and Gillis used the phrase "Design Friction" to describe this concept. They do not use the word gamification.
Gamification
The Design Friction concept is not the same as gamification. It can not be gamification when it it in a game:
Gamification: the use of game design techniques, game thinking and game mechanics to enhance non-game contexts.
The use of design friction is one way to shape fun in gameplay.
Reducing friction in new product development networks
Most of the time, individual contributors (which includes people with diverse functional specialties such as designers, developers, scientists, engineers, domain experts, and communication specialists involved in new product development efforts) strive to reduce friction for the intended users of a new product. Typically, gamification can be used to:
Make the technology more engaging
Encourage users to engage in the desired behaviors
Facilitate a faster path to making the user successful in accomplishing their goals
Introduce fun into the user experience
Designing for fun in new product development networks
New product development environments are impacted by friction. Popular options that networks may consider include:
Adoption of new tools
Evaluation of new, explicit practices, methodologies, principles, and theories
Analysis of metrics
Re-arrangements of the organizational chart
In my experience, the previously listed items tend not to produce fun for individual contributors. Most of the time, the previously listed approaches do not reduce friction and promote flow.
However, the concept of design friction can be applied to items such as:
Improving the perception of autonomy, mastery, and purpose [this has been described by authors such as Daniel Pink in his book Drive] of individual contributors
Improving cooperation, collaboration, and harmony within the network
Future posts will explore specific approaches to applying the Design Friction concept to upgrade new product development (NPD) paradigms.
How does one proceed when the objective is more success from product development efforts? What choices should be made when the votes that matter most are those of the customer? Is there another important factor?
Contrasting ten approaches to new product development
Recently I heard someone present survey data that listed problems associated with new product development. In my opinion, the report didn't provide sufficient inspiration for new and effective solutions to common problems. Although there were characterizations of problems for managers of new product development teams, the guidance for 'how' to solve the problem was missing.
I do not learn much from the survey results but the incident did provide the catalyst to summarize a few of my evolving convictions
Some NPD leaders want bigger teams and massive project budgets. I prefer smaller teams that operate with implicit coordination and earn support as they create value.
Some want to be assured of stability and to study the market until they have reports to legitimize their assumptions. I prefer to validate assumptions with well-crafted experiments.
Some only move when there seems to be abundant stability. I have trained to handle changes because they are an intrinsic aspect of development and they provide opportunities to evaluate my proficiency.
Some groups detest changing priorities. I prefer to shape priorities. I do not want to be paralyzed by them.
Some teams want to be provided with detailed project plans. They want a list of product requirements. I don’t want these thrust upon me. I prefer to provide valuable input to discover customer’s needs and evolve the plans.
Some individuals want to be told what customers want. I don’t want to be given a summary of the customer’s needs. I prefer to participate in gathering and testing insights and exploring the raw data.
I don’t want more planning by administrators. I don’t want a more adaptive plan. I want more fit and adaptive contributors.
Some development professionals want to extend the deadlines of their long duration projects. I advocate shorter, more focused efforts.
Some practitioners will tolerate some trial and error in their approach to new product development. I want to be certain to win because I am grounded in great theory and have gained competence. I strive to improve my performance through continuing deliberative practice.
Some managers evaluate the performance of their new product development teams using metrics that relate to on-time, on-budget, and on-scope project compliance. Some use local metrics such as story points per sprint. It is no secret that these metrics can be gamed. I have come to regard such metrics as proxies for effectiveness. For me, the most important factors that impact team performance include items such as the quality and quantity of my learning, the professional growth of other contributors, the effective use of time and skills, and an increase in respect for my colleagues.
The Principle of Obliquity
The approach I prefer is based on the Principle of Obliquity which states that it is best to pursue some objectives indirectly. Instead of focusing your resources on developing a profitable product under an explicit process, consider creating value for specific groups. Two choices include the people that will use the product and the individual contributors developing it.
Much has been discussed about how to design an appropriate user experience and the customer-facing aspect of new product development. There is an abundant amount of information on the impact of social media on new product success.
As a new product development synergist, I have a passionate interest in understanding how individual contributors coordinate and collaborate within a network. Under certain conditions, the network of individual contributors produces many desirable results.
What are the factors that are more likely to result in success for individual contributors to new product development efforts? What may transform someone from an attitude of indifference (such as 'I am working for a paycheck' or 'I put in my required time today') to engagement?
According to the Self-Determination Theory there are three innate needs for optimal function and growth. They are competence, relatedness, and autonomy. A recently popular version of this theory is described by Dan Pink in his book "Drive" He selected the words 'autonomy, mastery, and purpose.'
The best projects
I enjoy hearing stories from competent individuals that have had many opportunities to participate in new product development projects. Some of my favorite stories have been prompted by a question such as "Can you tell me about the best project of your career?"
I do not think that any of the 'best project' stories have extolled micromanagement, Gantt charts, excessive bureaucracy, or boredom. I do not think that the introduction of a new filing system, project database, idea management system, or a version tracking system have been mentioned in one of the stories that I have heard. Sometimes the stories mention the development of a wonderful new product.
Recurring elements of 'best project' stories included references to gaining respect for colleagues, learning valuable new skills, gratefulness about the time team members invested to pursue a worthwhile goal, making new friends, and team cohesiveness. It is no surprise that there is significant overlap with the 'autonomy, mastery, and purpose' factors described by Dan Pink when he talks about motivation.
New 'best project' stories
I have had a few projects that are candidates for a story about the 'best project of my new product development career.' However, because of better insights and deliberative practice, I predict that my 'all time best project' story will be based on a future project.
Perhaps you have a 'best project of your career' story. Hopefully, another story will be based on one of your future projects.
"We offer our engineers “20-percent time” so that they’re free to work on what they’re really passionate about. Google Suggest, AdSense for Content, and Orkut are among the many products of this perk."
"Atlassian's "FedEx Day" is time set aside for developers to work on whatever they want with a skew towards our products. We tend to run "FedEx" with a fairly open format where you can do whatever you want as long as you can somehow relate it to our products."
What happens on the other days?
What happens during the other days? At Google, what happens the other 80 percent of the time? At Atlassian, what happens the other 58.5 days of the quarter?
It is easy to recall the opposite of 'passionate' and 'do what you want.'
Certainly, representatives from Google and Atlassian didn't intend for someone to infer that employment at their companies was unappealing on the other days. Certainly, Dan Pink isn't suggesting that companies limit the pursuit of autonomy, mastery, and purpose to special days.
Goals for 2012
During the other days, Google, Atlassian, and your company will strive to do what they believe is best to accomplish their missions. Special days will be a part of the strategy to do that and remain a successful business.
My goals for 2012 include:
Publish more on the causal principles of NPD success related to individual performance and interactions
Reduce internecine warfare that arise from functional silos within development organizations.
Increase the coherence of new product development efforts
Provide more compelling input to those in new product development leadership positions
Improve my agility. Help others improve their agility.
Create more virtuous circles to help others in development networks
Minify time in boring meetings
The list is partial and it is long. It will take my best efforts and a lot more than 20 percent of my time.
Recently, I was asked "Should a web designer know how to code?' Before answering, I realized that it would be wise to clarify the context of the question.
Knowing the context informs the answer
It is critical to contrast a web context and a more general new product development (NPD) context.
In a web context, a 'designer' moniker implies that one is likely to use Adobe Photoshop as a primary tool. Typically, there is a professional pride in items such as font selection, kerning, and the parameters of drop shadows. A 'developer' role may be split between 'front-end' and 'back-end.' Typically, a 'front-end' role includes references to the code that is communicating with the browser. This means that a 'front-end developer' is likely to have a proficiency using HTML, CSS, and Javascript. A 'back-end' role is likely to emphasize code running on a server or the attributes of the database.
In product development, 'front-end' typically evokes a time dependent role. Someone that works in the 'front end' emphasizes their contribution early in the development effort. They may contribute to brain storming and ideation sessions.
If the question is in a web context, inquired about the production environment. If the production team is small (less than three or perhaps five people), many of the contributors may tend to generalize and have multiple roles. In larger production teams, specialization is more likely.
In some production environments, there is 'designer' versus 'developer' culture. In this type of workplace contributors are organized by functional specialty (in silos) and progress may be measured by transferring files between specialists (handoffs). In such environment, these may be sufficient cooperation but opportunities for more collaboration.
The debate
Sometimes a question such as 'Should a web designer know how to code?' escalates into a debate.
One position is that an individual should specialize in order to master their craft. Advice to an aspiring new contributor may include an admonition to read the classics in an attempt to uncover the principles. Other advice may be to study the contemporary examples and learn about the new techniques from the acknowledged masters of the craft.
Another position may be to consider the effort from a holistic perspective. Questions such as 'What is the business objective?' or 'How can I structure my contributions so that they can be integrated into the final solution by others?' may guide one's approach. Some may emphasize opportunities for cross-training. Others may suggest that knowing a sufficient amount of the jargon (vocabulary associated with a specific discipline) is sufficient. Others may suggest an understanding of the end-to-end process to ensure that one's contributions align with the ultimate objectives of the project.
An aspiration for contributors that are producing content for a multi-device world
The question "Should a web designer know how to code?" was the topic for the 14 December 2011 meeting of Refresh Pittsburgh. This group is 'A community of web designers & developers working to refresh the web design industry in Pittsburgh.'
The meeting ended by quoting Ethan Marcotte an independent designer and developer. He posted:
"In this brave new multi-device world we’re all designing for, I’m convinced more than ever that designers and developers need to be working more closely together. I spent the majority of my year on a large responsive design project, where the traditional “design team” and “development team” divide didn’t exist. We realized that our respective tools—a design app on one hand, HTML/CSS on the other—can’t design beyond the desktop without help from the other. Starting with a mockup, testing ideas in prototypes, bringing elements back into Photoshop for further refinement—that kind of “back and forth” worked incredibly well for us, and I’ll be looking to bring that collaborative approach into my future work."
Is transformation possible? How soon?
In considering the question 'Should web designers know code?' one approach may be to start with the following passage and substitute 'designer' for 'artist' and 'website' for 'game.'
“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.
Perhaps 'Should designers know code?' is not the best question.
If a team already has the services of a valuable contributor that is a designer that doesn't know code, sending them to 'code-camp' isn't going to help this project or the next one. The result will be the same as if you gave them a "Learn how to code in 3 days' or a 'Code for Dummies' book. Peter Norvig covered this in 2001 in his "Teach Yourself Programming in Ten Years" post.
Perhaps alternative questions are 'What can be done to maximize the value of the contributions of my non-coding designer to this project and the next?' and 'What can this non-coding designer do to improve the contributions of others (including the ones that are coding masters) on the team?'
Kobayashi Maru Thinking provides an approach to solve intractable problems.
Requisitioning nine women
Perhaps you have heard the following riddle.
If it takes one woman nine months to produce a baby, can nine women produce a baby in one month?
Many people come to the conclusion that there is not a clever answer to this riddle. In addition, they find a bit of humor in the way the riddle is presented.
How long will it take to complete my project?
This riddle is based on a statement from the classic book The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks, Jr. While at IBM, Brooks added more programmers to a project falling behind schedule. The rate of progress on his project didn't improve. He concluded:
“The bearing of a child takes nine months, no matter how many women are assigned.”
The statement is used to support advice commonly known as Brooks' Law
"Adding more people to a project that is already late will make it later." - Brooks' Law
Brooks' Law suggests that a no-win situation exists when a project is late. Possible options seem to be limited:
Add resources
Don't add resources
One argument for adding resources is that new specialists will enable other team members to focus on assigned tasks and the project tasks will be distributed so that everyone's workload will be more manageable.
Typical concerns about adding people include:
The people added to the project will consume precious development time.
The new people will detract from the productivity of the existing team members while they are becoming familiar with the project.
Adding more people to the project will increase the communication overhead and keeping the project synchronized will be more difficult.
Typical arguments for not adding resources include:
An acceptable outcome can be achieved through persuasion. The proper incentives will increase productivity.
Maintain the budget. There is a perception about saving money in the short term. There are suggestions that shortcoming can be addressed later or by some other group.
Changes will be disruptive. Making changes will have negative impacts on the current efforts.
Problems that may result from not adding resources include:
An overworked team will not be able to complete all the required tasks.
There will be other negative consequences.
Additional mistakes and will be made.
Individuals are more likely to suffer from fatigue.
A problem with too many new product development projects
It is common for new product development projects to be late (or to fail) for many reasons, When choices are made to add resources, unsophisticated decision makers are likely to make sub-optimal choices that may produce some of the following results:
Promised project completion dates must be re-evaluated
User experiences degrade for users of the product. Disappointed users write negative product reviews.
Extra work for the post-sales support team to fix problems that were not addressed during development
Progress is hindered on the next new product development project
Sub-optimal choices are not likely to produce great products that position companies for maximum success in the future. This post reviews some common beliefs about troubled projects and then addresses one way to overcome what may be perceived to be no-win scenarios.
Note: "Sometimes, Brooks’ Law is cited inappropriately as an argument for not adding resources to an understaffed project. In addition, Brooks’ Law does not apply directly to contributors that perform tasks that can be easily partitioned and isolated—those tasks that do not have a significant learning curve and require minimal communication." [2]
How does one overcome what appears to be a no-win situation?
No-win scenarios
Question: Who is noted for saying "I don't believe in the no-win scenario."
Answer: Captain James T. Kirk in the movie "Star Trek II: The Wrath of Khan." Kirk was referencing his experiences with the Kobayashi Maru test.
In the Star Trek culture, a Kobayashi Maru reference reminds fans of an apparent no-win scenario where a solution is possible by changing the starting conditions to redefine the problem.
Kirk overcame the apparent no-win scenario of the Kobayashi Maru test by changing the starting conditions. In contrast, he escaped the Genesis Cave by out-whiting Khan.
Changing the Starting Conditions
Let's review the original riddle and re-examine the goal. The desired goal was to produce a baby within one month. There were no requirements specified regarding the woman. There were no explicit requirements regarding the number of women. There were no other project constraints.
To achieve the goal, one solution involves altering the initial conditions by selecting a woman with an offspring already developing in her body. Note that it is the same woman as shown in the first image but this image reveals a fact that was not shown earlier.
By changing the appropriate starting conditions, one can achieve the desired result within the desired time.
Changing the starting condition for new product development projects
Kobayashi Maru thinking is characterized by changing the starting conditions to solve an intractable (wicked) problem. It does not involve:
A Compromise
Turning a difficult situation into an opportunity (a lemons to lemonade approach)
A Hobson's choice (a free choice where only one option is offered. A 'take it or leave it' choice)
A Pivot (as defined by @EricRies and the #LeanStartUp advocates is changing directions (vision) but staying grounded in what you have learned )
How will you close your next innovation gap (the time between the product concept and delivering value to an abundant number of customers)? How will you get to great faster that your previous attempts or faster than competitors?
I will not provide recommendations to overcome specific problems in this post. I can summarize several factors that may inspire more creative starting conditions. These include:
Enlist individual contributors with the an abundance of domain knowledge and a mastery of their skills.
Facilitate interoperability within the development network (encourage cross-functional cooperation and collaboration, improve communication,...)
Evolve combined efforts produce the appropriate experience for the users of the product
Adapt development models better suited for development networks (environments where many individual contributors are either geographically dispersed or where individual contributors are employed by separate organizations)
Kobayashi Maru Examples in New Product Development
One example of Koybayashi Maru Thinking was documented in my first article in Visions Magazine - How to Change Direction in New Product Development in 30 Days without a Budget [3]. This case study from HP documents the transition of someone in the role of documentation specialist to designer. Instead of complaining about the product's user interface, it was changed without a project budget increase and within the previously defined time constraints.
Many Kobayashi Maru Thinking examples relate the story a person changing hats (roles) for a finite period. In the Star Trek example, Kirk role changed from test taker to strategist and programmer.
Do you have another example of Kobayashi Maru Thinking in new product development? What starting conditions can you change on your new product development project?
One team experimented with ideas and concepts but didn't build interactive prototypes. The other team advanced their learning by building and testing interactive prototypes faster than their competitors.
The Original Concept from the Google team
As an April Fools Day contribution, a team at Google presented a product concept. They released a video for a faux product - Gmail Motion BETA.
The pitch for this product was ‘Using your computer’s camera and a spatial tracking algorithm, Gmail Motion tracks physical movement and turns it into actionable commands’
This product video was moderated by Paul McDonald. According to his LinkedIn profile, he is the current GMail product manager. During the video, the apparent functionality of the product was faked using common video production techniques.
From conception through production, I suspect that the video required at least a day of effort by a small team. Video production incorporated studio lighting, high quality audio, a finely tuned and edited script, high quality animations, and a supporting cast.
The team at Google knows that much of this product concept is cumbersome. It is reasonable to assume that although they have sufficient resources to develop many product concepts, the Google team understands that this product concept is impractical.
I was entertained by the faux product video.
Crafting a Functional, Interactive Prototype
Later that same day, another team from the University of Southern California Institute for Creative Technologies (USCICT) posted their video on YouTube (a Google property). From the project description provided by the Google team, the ICT team developed an interactive prototype using a Microsoft Kinect system and functionality from their FAAST project.
The system was demonstrated by Evan A Suma, Ph.D, a Postdoctoral researcher. One commenter stated ‘consequences will never be the same.’
I admire the team the built the prototype. They integrated their technology and demonstrated a working system in approximately one day.
You are what you practice
Expanding on the ‘You are what you practice’ concept, one company produced the faux product video that reflects their capability for creative humor. Their deliberate practice has prepared them to produce another humorous video. The next time, their video production may be faster.
The ICT team produced a video that captured my imagination. Their video demonstrated their toolkit. The speed of their response to the faux product video from the Google team, demonstrates their ability to implement and iterate and learn.
On 5 April, Evan Suma of ICT wrote "the Gmail marketing manager contacted me yesterday and said they thought the video was awesome, and thanked me for doing it"*
The ICT team can produce valuable consequences faster.
The actions of the ICT team remind me of Colonel John Boyd's OODA loop described in a book by Chet Richards. The aptly titled book is Certain to Win.
* e-mail correspondence. Evan A Suma and Mark A Hart
During new product development, some problems are fatal. In other cases, certain factors may limit the success of development efforts.
To facilitate the discussion of items that impact qualities such as the efficiency or effectiveness of new product development, I began using the phrase "Success Limiting Factor" (SLF) on 11 December 2010.
The intent of the phrase success limiting factor is to convey an explanation that avoids linear reductionism. The intent is to provide insights that are more subtle than overly simplistic conclusions about "the weakest link."
Rationalized post-project review comments
Perhaps you have overheard conversations in a post-project review session that can be summarized by comments such as:
"The project was a success but our timing was bad. The problem is the economy."
"The project was a success but our target customers are buying the competitor's product. Our competitor has more resources."
"The project was a success but the news of a few minor defects hurt our sales. Why can't our marketing department do a better job of controlling what is posted on Twitter?"
Instead of congratulating ourselves regarding internal metrics, new product developers should be reminded that when we fail to deliver value to an abundant number of customers, the project failed.
Impacts of SLFs
SLFs are items that impede new product development. They are detrimental to success. There are many SLFs and each has a unique relative impact. The most important indicator from all SLFs is the impact at product launch. This is the aggregate indicator.
Some SLFs have a deterministic nature. In some cases, there is a simple cause and effect relationship. These types of factors have first-order effects.
In other cases, the relationship between an SLF and the impact is more complex. These types of SLFs have second-order (or higher) effects. The impact varies because of interactions in the system. For more information refer to the Wikipedia entry for a complex adaptive system.
Achieving more success with less wasted effort
For a given set of project constraints (budget, resources, scope, time table,...), what does it look like when a team achieves better results? When plotted as revenue versus time, the desired outcome is more success for the development investment. This is more return on investment.
When SLFs are reduced, customer's are more likely to recommend a product to their friend. This is the basis for assessments such as net promoter score.
In future posts in this series, I will identify specific SLFs and suggest ways to reduce their impact.
Have you ever reminisced about your best experiences in new product development teams. I have. I wanted to be able to explain why some experiences were outstanding.
Explicit coordination
Some organizations embraced a sequential development approach that transfered responsibilities from one group of specialists to another. Projects proceeded in mutually exclusive phases. Progress was assessed by management at predetermined times. This approach relied on central control and explicit coordination.
Explicit Coordination includes coordination via planning and coordination via communication which includes feedback processes, personal coordination, and the exchange of information (1)
Information was stored and knowledge was managed.
Typically, job classifications were used to select project resources. Sometimes, it was presumed that individuals were interchangeable if there was someone with a similar curriculum vitae in the talent pool.
There was tension between engineering and marketing. Sales and Marketing had different priorities. There were debates between individuals with titles such as Product Manager, Product Marketing Manager, and Product Owner. Within the 'research and development' group, some individuals considered themselves a Designer while others claimed the role of Developer.
Often, it was just logomachy - a dispute concerning words. The origins of the misunderstanding could be traced to experiences from another prevailing framework or another company culture.
Implicit coordination
Implicit coordination is a team interaction behavior. It is a process that takes place when “team members anticipate the actions and needs of their colleagues and task demands and dynamically adjust their own behavior accordingly, without having to communicate directly with each other or plan the activity”
When there is implicit coordination, individuals do more than just 'turn in their assignment.
When implicit coordination thrives, collaboration equity is maximized.
Collaboration Equity is the amount of positive value your NPD receives from the totality of your efforts to maximize collaboration effectiveness.
I prefer teams that are paragons of implicit coordination. The Rico et. al. article includes of model that details the contributions to team implicit coordination processes.
I will provide several suggestions to facilitate implicit coordination. I welcome your suggestions.
1. Ramon Rico, Miriam Sanchez-Manzanares, Francisco Gil, and Cristina Gibson. 2008. “Team implicit coordination processes: A team knowledge-based approach.” Academy of Management Review, Vol. 33, No. 1, pp. 163-184.
In the Agile Manifesto, the statement,"Individuals and interactions over processes and tools," declares relative value from the perspective of the signatories. In other development environments, processes and tools may seem to command a lot more attention than people. A people versus process discussion may polarize many participants.
This post explores a potentially more polarizing idea:
"In New Product Development (NPD), processes are incidental to the value stream" (1)
Value Stream: The an end-to-end business process which delivers a product or service to a customer or consumer. The process steps along the way may both use and produce intermediate goods, services and information to reach that primary end.
Analysis may suggest the removal of intermediate process steps, goods, services and information that do not move the value stream forwards to its primary end, provided they do not serve important secondary ends such as compliance, quality control or employee loyalty.
Initially, the value is realized at launch when people begin to interact with your new product.The value depends on the user experience with your new product. For the most part, customers don't care too much about your processes.
Speculative Products and Speculative Processes
In NPD, most projects begin as speculative product concepts. A speculative product is not developed for a particular customer and there are no guarantees that sales will be abundant. Your 'finished' product may not have a great product/market fit. If your product doesn't have traction in the marketplace, an expensive advertising campaign or extensive public relations effort will be inefficient.
The product concept is speculative. The processes used to commercialize the product are more speculative even if it is implied that the processes are aligned with 'Best Practices.'
Incidental
Incidental doesn't imply unimportant.
It is a reminder that NPD is a multi-variable problem and the desired primary output is value in the economic domain. Sometimes contributors to NPD get distracted by proxy variables such as waste, cycle time, variability, efficiency, and unit cost and processes. (2)
In new product development, mobilize your team to delight customers and incidentally you can publish the results on your brilliant processes that facilitated your success.
Acknowledgements
1. The title of this post was inspired (in part) after viewing a presentation by Hal Macomber on Target-Value Design at the UK Lean Conference in 2009.
Recent Comments