Skip to Content

Is co-innovation worth the trouble?

Don’t get me wrong – I am a huge fan of co-innovation ; with my colleagues, business partners, clients, friends, fellow dog trainers etc. A group (at least 2 people) come together, share their resources and experiences, and come out with a product or service or something, that is usually better than what is possible if only one person tries. I am sure all of you have experienced this in some form or other in your every day life, within and outside work.


However, for all the benefits of co-innovation, I run into a bunch of issues that make me scared of doing it “big time”.


Here is a “fictitious” story to set the context. You have a young dog that bites. You don’t want to get rid of the dog since your kid loves the dog too much. So you decide that you need the service of a professional trainer. You also figure that an animal behavior expert might be a good addition to the professional trainer, just to cover all bases. You just want to get the best solution, since you don’t want the dog to ever bite anyone, including your kid.


You get reccomendations from several people, and finalizes on a trainer and an animal behavior expert. You agree to pay them both a certain sum of money for their services.The objective is to stop the dog from biting in 6 months time. You promise to pay the trainer in instalments, based on his successful completion of certain milestones. The behavior expert gets paid by the hour.


The trainer is the best in business, and so is the behavior specialist. In return for solving your problem, they both need good references from you. You have promised to write good things about the trainer on his website, and to allow the behavior specialist to use your “case” as an example in her upcoming book.


The project starts and you sit down with the trainer and the behavior expert to chart out the plan. All three of you agree on the way forward, and then you let them do their job. You are busy with your life, and checks in occassionally to check for progress.


After a while, you sense that not all is well. The behavior expert questions the trainer’s methods – and points out that he didn’t mention some details upfront when every one agreed to the plan. She can cite a lot of cases where his current methods have failed before, and also why it is more of a quick fix and not a long term solution. On the other hand, the trainer argues that his methods will work , and the reason to modify some of the methods was because your dog proved tougher than he originally assesed. Since he is the expert in the group, he just didnt think it is a big deal to let you and the behavior expert know upfront. While these two argue, you mediate – and continue to pay them both. Mind you – the dog still bites, since nothing has been done to solve the original reason for hiring the team !


So you sit down again with the two experts. You agree on a new plan – and realize it will take one year instead of 6 months to get your dog trained. Your kid is too attached to the dog by now, that you feel it is ok to splurge a little more. Hower you don’t want to pay twice as much – so you negotiate a deal with the trainer, to get a discount. The behavior expert decides to show up for only every other session, so that you can stick to your original budget. This time, everything works well – and your dog is now apparently a non-biter. Every one splits their way happy. You pay every one as promised, and also write references.


A year passes by, and guess what – the dog starts growling again. You rush to find the trainer and the behavior expert. Behavior expert is now living in Spain with her new husband, and the trainer is busy training dogs for a movie studio. So – you hire a new team and start over. (or if you prefer a sad ending to the story – say you gave the dog to an animal rescue group or shelter, and drove back home with a kid who will hate you for a really long time ).


I am pretty sure a lot of you (including “cat” and “fish” people ) can relate to this story in some form. We also face this scenario a lot in corporate world. Co-innovation comes in a lot of flavours, and probably not all parties need to be paid in cash to innovate. Nevertheless, as we saw in our little story above – lack of governance can make co-innovation difficult to practice, and impossible to sustain.


In the next blog, let us kick around some ideas on how to make this process  better.

You must be Logged on to comment or reply to a post.
  • In the words of the warden in Cool Hand Luke: “What we have here is a failure to communicate.” Actually it is much more than that.

    Projects that go wrong in this fashion are almost ALWAYS the result of poor management. The guy saying that he didn’t tell you upfront about certain things is talking nonsense.

    Why were you continuing to pay? Where were the milestones?

    • hey Dennis,

      Thanks for reading and commenting.

      When things go wrong half way through – the project managers have a real hard time. Do you scrap and start afresh, or do you try to salvage and put in a better plan? It is a hard call – and there is only so much we can predict on the outcome of the new plan.

      Why would you continue to pay? good question. The dog (piece of software) is very close to your kid’s( the business’) heart. The only reason managers continue to fund such projects is because they think they can salvage and get something good for their business users. If it was my dog, and not my kid’s dog – the trainer would be fired first time itself.

      In fairness to the trainer, not all plans and estimates work in practice – so he might have had to change course. The issue is he didn’t think it is important to communicate to the rest of the team.


      • @vijay – things never go wrong half way through. They go wrong well before the point of failure.

        One way to help avoid this is Scrum Methodology. The 2-week sprint keeps everyone focused and provides a way to ensure that ‘things’ further down the line don’t get clogged because of lags elsewhere.

        We used it when developing ESME and it worked a treat. We made our deadline and got done everything we originally planned.

        There are lots of other techniques that can be used but for the best advice check out my colleague Mike Krigsman: who talks about the causes of failure and how to avoid them.

        • In my programming days, I had tried out several variants of agile programming – but did not have consistent results.

          When everyone was available together in an office – business, programmers, functional guys etc; it was extremely good. But this is an exception in global projects.

          For me personally, the biggest challenge was in making it work in global teams with different experience levels, different cultures and of course working in different timezones. Eventually it ended up as a hybrid – probably resembling more of waterfall than say scrum.

          btw, I liked your friend’s blog on project failures – thanks for pointing it out.

          • Yes – agree that there are issues in global teams (ours is spread across the globe in 6-7 countries) but a lot of the problem comes down to discipline. Agile demands discipline and I’m not sure that many devs are that disciplined by nature. (lol)
        • Thanks for the blog shout-out. I totally agree with your statement things “go wrong well before the point of failure”. Truer words were never spoken.

          We’re all aware of projects where the team “suddenly” realized the dates wouldn’t be met, the budget would be over-extended, etc. Most likely, every individual participant was aware of some type of problem. However, no one was brave enough to actually speak up and try to fix things. Instead, every person was waiting for someone else to stand up, so the other person would take the heat. I understand this, because unfortunately it is indeed true that messengers often get shot.

          So, the sudden team realization was actually composed of individuals not honestly communicating their opinions and best judgments with the remainder of the team, earlier in the process.

          I’m not criticizing anyone here, just trying to point out a failure-inducing dynamic that happens all the time.

        • I just finished reading the Demo Jam story at The specified item was not found.

          And this reminded me of your comment that things will actually go wrong well before the point of failure. Isn’t this story a good example that despite scrum etc, things can actually go wrong at any point – and there is only so much you can do in terms of planning?

          ( btw, I do love the ESME story, especially the learning that finally, it is the people that matter)

  • Vijay,

    Your most interesting point is about how the resources who did the work are no where to be found.  As much as everyone talks about “handover/turnover” planning, it seems that you still can’t account for when someone leaves and does not come back.  IMHO, project methodolgies are insurance policies which still can not address everything.

    An interesting concept would be what if the top folks on SDN just suddenly left, would things still continue and what would happen?  I mean sometimes the it is the people involved in the activity that drive the project and not the organization itself.

    So how much consideration to participant burnout has been made in the new web 2.0 concepts?  You can make things as “social” as you want, but people can/will eventually drop from the conversation.

    Take care,


    • Bingo!
      Life moves on, and more interesting things will lure people away.

      Sometimes, it is not “people” alone who are irreplaceable – it could be companies.

      Sustainability becomes a huge issue.
      One advantage of sticking with standard software is that the vendor promises long term support in return to some licensing fees. However, this might not be enough for you. This still doesn’t provide for changing requirements as time progresses. Business is dynamic, and what worked today might not work two years from now. Licensing fee buys a commitment that issues with today’s system will still be resolved if it comes two years from now. But it does not necessarily guarantee that the newer requirements will keep getting added to the standard suite.

      In a “social” media situation, where the general idea is content is not “paid for” by any one, this should be an even bigger issue. How do you ensure that solutions evolve over time?