How to be a champion for innovation- Part 2- Talk tasks when you can’t talk facts

Hello Troops,

Today lets talk about how to communicate with others at the beginning of a discovery project.  The beginning of any project or program is difficult because it is the time when your leadership has the most questions and you have the fewest facts.  I don’t know about you but I hate having to say “I don’t know or We’re not sure” over and over and over.  To combat this I’ve taken to proactively sending out meeting minutes and update notes that lay out our task based strategy for the next one to two weeks.  These notes help in two ways.  First they communicate that the team is working and making progress.  The Fuzzy Front End makes a lot of managers nervous because the team is out and about and there is very little evidence that actual work is being done.  So by sending out notes that outline who is where and why and then following those notes up with what they learned, everyone is able to see progress.  Many folks I talk with are nervous about sending out updates before the team has reached a proper conclusion.  I have found that it can be much more satisfying to bring your leadership along the journey with you instead of waiting for a big reveal at the end.

So my philosophy is to tell them our plan for the week in a brief outline with names and dates.  Then,  I look at what I’ve written and I ask myself, if I was reading this and I wasn’t on the team what questions would I have about this plan?  I then go back in and fill in a few descriptions where I think they might help others understand our strategy and direction.  This method has worked well for me over the last five years.  I find that my leadership feels connected and excited about the projects because they are up to date on our activities.  My boss also feels good because she isn’t alone in having to communicate what the team is doing all day.

There’s something else about this type of communication that I really like a lot.  It’s easy to catch quickly if the team is headed off track.  When you are reading or writing the summaries you are forced to take a minute and think about the program and direction it is headed.  Without these weekly updates it could be 3 months or longer before anyone even notices that the project has stalled, twisted or lost direction.  By the same token it is much easier to communicate dead ends and new directions and often a full review is not necessary for these changes because everyone reading the update is familiar with the project and the decisions being made by the team.

So communicate the tasks even if they are small and seem obvious.  When you look back on those notes later, as the team moves into the more concrete portions of the project you’ll have a great diary of how you discovered your direction and who was along for the ride.

Soldier On !


How to be a champion for innovation Part 1- Help communicate progress

Hello Troops,

I’m back from New Orleans and I brought home with me a few good tidbits on technology mapping and developing new products for emerging markets.  It was a good conference and as usual, the main benefit of attending was the networking.  I was one of the last presenters and I was pleasantly surprised to find myself speaking to a pretty full room.  As I mentioned in my previous post, my talk was on the topic of communication.  I presented three ways that leaders can support their teams as they move through the fuzzy front end (FFE) of product development.  The 30 min talk was sectioned into three parts.   First, help teams communicate progress in a way that is meaningful to people outside of the team.  Second, ask the right questions using words that motivate and encourage the team.  Third, be the voice for innovation in parts of the business that are not directly connected to the team and their activities.  It would be interesting to know if folks that listened to the talk were able to take away these key points.  I was nervous and I found that even though I practiced the talk prior to presenting I still rambled a bit.  I always look back on my presentations and think, would I have wanted to sit there and listen for 30 min ?  In this case I’d give myself a solid B.  I think I could have been more to the point in places and if I had another crack at it I think I could have been a little more prescriptive and a little less preachy.  But on a whole I was pleased with the way the presentation flowed.  One of the best parts of this particular conference was that the audience was made up of executives and innovation managers.  I was lucky enough to be able to talk directly to the people who could most benefit from hearing the message.

As promised, I’ll share here a bit of the takeaways from my presentation.  Today we’ll talk about communicating progress.  Communicating progress to people outside of the team can be a huge challenge. Team leaders and champions need to build and maintain momentum for their teams keeping in mind that it’s a marathon not a sprint. Communication should be planned carefully so that the team has support along the entire project route.  One of the easiest ways to achieve consistent support is to give regular updates to the people who are depending on the project’s success.  Don’t wait for the gate review to share !  During these updates the team needs to focus on sharing how they are making progress.  My suggestion to teams early in the development cycle is this, communicate your action plan, communicate your accomplished tasks and how these tasks have moved the team forward and then communicate your next action plan.  You talk TASKS so that they can have FACTS to share with their bosses.  The more tasks you accomplish the more facts you’ll have to share and the more facts you have the closer you’ll be to a direction and scope for your project.  Laying out your plan for leadership does three things.  First, it gives them a framework for talking to others about the project.  They can communicate FACTS, “the team is currently out in the field gathering voice of customer data and then they will be summarizing that data using a KJ anlaysis” .  Second, it gives them a road map to follow.  They can not only talk about where you’ve been but they can also talk about where you are going next.  Third, and probably most important, it gives them a sense of flow for the project, that essential feeling that you need them to have, the feeling that the team is moving and making progress.  Talking about what you are doing and why can be just as important, if not more important, than the results especially in the beginning of a project.

If your team is struggling to communicate progress (getting lots of phone calls from your boss asking you questions about the program?) you may need to step in. Ask them to lay out their plan and list out the tasks to be done and what will be done with the data from those tasks.  Then help them create a communication plan based on explaining the tasks to be done and sharing the results. Let the team leader send out the communications to build confidence in their leadership with the stakeholders.

A side benefit to this type of communication and leadership is that you always know what’s going on with your team, eliminating those embarrassing situations when someone asks you how it’s going and you have nothing to report.  It also gives you the ability to help steer the team without looking too heavy handed.  Rather than dictating a direction, you can simply suggest adding a task to the list.

Communicate early Communicate often Communicate results.

Looking for a great Discovery/Idea/Concept Phase road map?  I recommend Gijs van Wulfen’s FORTH method.  He’s got 2 books on the subject and a great strategy for getting teams through discovery phase.  What I like most about using FORTH is that it sets up your discovery tasks and lays out a time frame for reporting back in your results.  It’s an especially good process for teams with brand new project leaders.

Soldier On !


How I present at conferences even though I work on top secret stuff.

Hello Troops,

Today I blog from New Orleans, The Big Easy, where I’m going to attend and present at a conference.  Well I think it’s a conference.  I’m not actually sure what to call it I guess.  The event is called 8th Annual Innovation in New Product Development and Marketing:
A Frost & Sullivan Executive MindXchange.  
I know right? It’s a funny name for a pretty serious conference on how to accelerate product development.  I’ll be speaking about how to communicate project progress when you are in the very beginning stages of discovery/idea/concept development.  It’s actually a big problem for many teams working in the “Fuzzy Front End” of the product development cycle.  How do you communicate progress when you have very few facts to communicate?  It is the very exploratory nature of the discovery process that makes it so difficult to communicate to stakeholders.  They want facts and answers and timelines and costs.  You have… none of these things.  All you have is a room full of directions to explore and people to talk to and materials and technologies that look interesting. So what’s a discovery team lead to do?  Well that’s what my talk will be about :)  Probably not fair to let the cat out of the bag until after all of the fine conference paying attendees have heard it first, don’t you think?

So, until I can share all of my communication secrets with you, let’s talk conference attendance and how I approach these events.  I’ve been going to conferences for over, ouch, 17 years.  My first conferences were academic and scientific conferences like ACS, PittCon, FACSS and the ICP Winter Conference.  I attended these conferences as a graduate student to share my research and learn about other academic research going on in my chosen field, analytical chemistry.  The purpose of these conferences was to give me experience presenting my research and answering questions.  I threw up before every single one.  I was a complete wreck, but I learned how to give a pretty decent talk.  My boss Dr. James Holcome (now retired from the University of Texas) was an excellent mentor and taught me a lot about being comfortable in front of a group of scientific peers.  He also taught me that it is ok to let your real personality show while you are presenting.  Be yourself, this is my first piece of advice to anyone getting ready to give a talk.  Once I graduated and started working I attended very few external conferences, mostly because in industry it’s generally difficult to share your research due to intellectual property and trade secret concerns.  Instead, I began to present inside my corporation.

My company has a pretty neat policy when it comes to technology sharing between scientists, share everything.  The complete support for trading technologies and ideas between business groups means that each year there are over 400 technical presentations and events. Plenty of choices for a scientist who’d like to get up and keep her presentation skills sharp.  My second piece of advice for product developers and team leaders is to present at least once a year for people inside your company.  It not only helps to keep you up to date on presentation tools and styles but it also helps you build personal brand inside your company.  It forces you to be out there, in front, telling folks what you’ve been doing and how your projects are going. Having said that, it’s true that in the last few years I’ve once again started to attend external conferences.

What’s the reason for the sudden change?  I finally figured out how I can have my cake and eat it too, or more specifically, how I can talk externally but not jeopardize the confidential nature of my projects. The trick is, I’m not going to scientific conferences. Instead, I’ve been attending industry conferences on topics that are related to product development and innovation.  These conferences allow me to present in front of an external audience without jeopardizing confidential projects or processes internal to my company.  I can give a useful and meaningful talk and never once mention what I personally am working on inside my company.  Hence, my trip to the Big Easy.  Here I can share advice from years of program management experience but never specify the exact nature of any of the programs.  My third piece of advice for product developers is to try this out for yourself.  I recommend finding a conference where folks are sharing on a topic that is general enough to allow you to “teach” them something without having to go into specifics about your project.  There are tons of these conferences and they are heart stoppingly expensive.  But that’s the other trick I’ve learned.  If you present at the conference, they will waive your attendance fee. All you have to do is get yourself there and you can soak in all of the information being presented for the price of working up a 45 minute talk of your own, win win.

Wish me luck as I prepare to wow this group with my words of wisdom on communication during the discovery phase.  I still get nervous before every talk but thankfully I no longer puke.

Soldier On !



All Quiet on the Innovation Front

“We came to realise – first with astonishment, then bitterness, and finally with indifference – that intellect apparently wasn’t the most important thing…not ideas, but the system; not freedom, but drill. We had joined up with enthusiasm and with good will; but they did everything to knock that out of us.”
― Erich Maria RemarqueAll Quiet on the Western Front

This quote spoke directly to me today.  Sometimes the process of innovation is a battle.  We are both leaders and soldiers taking orders.  Our enthusiasm and good will are key to the system’s success.  To operate at peak performance we need the freedom to express and implement our ideas.