Pitching Success – CO-STAR

Idaho National Labs has a program right now called “CO-STAR”.  Their researchers do great work, but as with any research group they are constantly advocating for funding, and researchers are constantly advocating among themselves for time.

Everybody spends time advocating for something.  “Pitching” something.  You want your boss to consider a smarter way of working, one that you’ve come up with?  You pitch it to her.  You want someone to use an open-source project you’ve created? You pitch it to them.

Some folks are naturals at this.

Nerds (researchers, open-source software creators, me) are often not good at this.  At least this is my experience.

I don’t like to brag about my stuff.  I have a much easier time bragging about someone else’s work.  I think a lot of folks have this specific problem with pitching – but of course there are a number of other sticking points folks experience.

The CO-STAR system is a way to break out of that a bit, because it is a process for performing a pitch that one can simply follow.  Moxie and a persuasive style may help a pitch, and CO-STAR can’t help those, but it does set out the requirements your target will need to evaluate your pitch logically.  It’s a set of steps you can follow in a discussion – and it’s even ordered!  In an actual pitch a more-experienced speaker may choose to skip some of the steps that are already understood by all parties, but one could simply progress through the steps in order and have success. This link is a description of the system in short.

First, you need an idea you want to pitch and a target to pitch to.  Perhaps you want your boss to let you adopt a new way of washing the dishes, maybe you want your company’s training division to send you to a conference, maybe you want a separate company to use your widget. 

Next, use a couple sentences to describe and answer each of the following.  These are quotes with only small clarification on my part, and these come from that PDF linked above, which is copyright 2017 Enterprise Development Group, Inc.

Your Hook: Begin with a compelling question, fact, or statement that will generate (in the mind of your target) curiosity related to your idea.

Customer: Who is the customer for your idea?  What needs do they have that might be met by your idea?

Opportunity: What is the opportunity for them?

Solution: What is your solution to their problem?

Team: Who needs to be on your team to solve this?

Advantage: What is the competitive advantage your solution provides over other solutions?

Results: What results will you achieve?

The Ask: Conclude with a specific request regarding the next steps your target should take.

Don’t spend too much time on the solution.  Most people get too excited about the solution because, after all, the solution was their big idea!  But your pitch target probably cares more about the other things like opportunity, advantage, and most of all results.

Remember that when considering your advantage one “other solution” is for your target to keep doing whatever they are currently doing.  Even if that’s “nothing”.  Make sure you consider the advantages of your solution over “doing nothing”.

Regarding the ask and next steps maybe you want a meeting with the target where you can discuss a way-forward in more depth, or maybe you just want to ask for the time and money to do your idea (in the event of conference attendance, for example, that’s all you might need).

The CO-STAR system is pretty simple, and anyone who has pitched before has used parts of it.  One benefit is that it lays steps out that, when followed in-order, clearly explain the value proposition you want to make.  It systematizes and simplifies a pitch.

There are a number of non-traditional pitches I’ve made recently… Websites, emails about opportunities, persuasive papers… All benefit from answering the questions in the CO-STAR model.

Meet Differently

A recent episode of the Freakonomics podcast covered meetings. Two or more people gathering to accomplish the business of business, as they defined it. It gave me some things I hope I remember the next time I’m organizing a recurring staff meeting…

  1. Organize an agenda around questions-to-answer
  2. Hold smaller meetings
  3. Keep track and time

Meetings need agendas, just about every book I’ve read which touches on meetings agrees on this point. The agenda needs to be communicated to participants in advance, so folks can come ready to accomplish it. Folks need to know what to expect. Without an agenda meetings usually devolve into chaos, although sometimes it takes a couple aimless meetings in a row to hit this point. Staff meetings often don’t have a pre-published agenda, but they generally do have a set of topics they proceed through in a set order, and that becomes the known-agenda for the group.

Generally my agendas are lists of topics – that’s not the most effective way to manage a meeting though. In the podcast Steven Rogelberg says, “if you can’t come up with any questions, you shouldn’t have a meeting”. A meeting isn’t for distributing announcements – there are other, better, less time-intrusive means for that. A meeting is for collaboration on problems, which can be stated as questions.

Organize an agenda around questions-to-answer

This also makes it easy to shake out the folks that actually need to attend the meeting. Getting everyone to attend is a waste of their time. Getting just the folks who have inputs on question answers is the minimum group for attendance. If others have input they can attend too after seeing the meeting agenda.

One question I’ve needed to answer in the past is, “what work from my team am I going to present to my bosses this week?” I’ve often taken it on myself to answer this question, but it occurs to me that the transparency I’d provide by bring this question to the workers, getting their input, and providing my feedback, could be excellent.

Smaller meetings, like shorter meetings, make better use of my folks’ time. When nugging the group of attendees down based on inputs required, I’m building a smaller meeting. I can also build smaller meetings by holding more meetings but with targeted groups.

For instance, when I led tactics development I could have met with the team leads individually to gather their inputs for the week. What’s their status update, what are their blockers, what are their accomplishments… This would have given me personal time with each lead (valuable), time to track their updates, time for them to provide me feedback they might not in a larger group, and time for me to provide them more private feedback. Then, our larger group meeting might have asked the questions, “which of these accomplishments are most valuable to raise up”, “which blockers can be solved in the group”, and “which blockers are most valuable to raise up?”

I actually did that on occasion, thinking back. Not in such an organized way, but as a result of intuition. There were reasons at the time I didn’t fully embrace the method (partly because it wasn’t my job but I felt like I still had to do it) so I did it only about 90%. A mistake.


Hold smaller meetings

If a meeting has questions for the full group, and also some for only a subset, after the full group part is complete let the folks unconcerned for the rest leave. Open the door, take a 30 second break.

For small staff meetings, to improve group openness, risk-taking, and personal connection, consider taking 10 minutes at the beginning to do “a rose and a thorn.” Everyone tells what they see as the best part and worst part of their week/week-to-come.

Keep track and time

Start on time, end on time. Set the meeting for the amount of time the questions will take, not some arbitrary value like “an hour”. If there’s pre-reading required, consider scheduling-in time at the beginning for folks to complete it.

Take minutes, and if the group decides work needs to be done and follow-ups need to occur then assign those tasks to someone. Write that assignment down. Discuss when you’ll expect the result, then come back to it later. Put all that in the minutes and send that out to the participants.

Announce “last call” at the end of the meeting, or as we do in the Air Force ask for any “reattacks”. Maybe plan for the last ten minutes for this, and set an alarm that shouts “LAST CALL” or “REATTACKS!” at that time. That’d at least be fun.

Folks are going to complain about meetings. We all do – even when they’re useful. At the least I can try to make them a good use of my folks’ time.

Consider How Well-Defined a Problem is When Building Teams

To improve innovation on a team, consider building a team differently based on the problem you’re facing. There are many ways of categorizing a problem your team must solve, but one is along the axis of well-definedness.

Well-defined problems – here, you know what you’re trying to solve, you know what end-state your audience will find acceptable, maybe you’ve seen similar problems solved elsewhere or you even know some current acceptable solutions.

Poorly-defined problems – these might be more general problems, things you’ve never encountered before, problems nobody else is even thinking about yet. Maybe your boss doesn’t know the full shape of things, or maybe the full shape of things is not yet knowable.

Research shows that for well-defined problems, having a less experience-diverse team can produce more innovative solutions. Diverse is a loaded word these days, but in the case of the research diversity was measured in terms of experience relevant to the problem. I’m calling that experience-diversity. So – for well-defined problems, having a team comprised of individuals already versed in the problem set produced more innovative solutions.

For poorly-defined problems, having a more experience-diverse team can produce more innovative solutions. Diversity, again, along the lines of folks versed in the problem. This means – if you don’t have a clearly defined problem, get a bunch of folks with a variety of expertise. This will help you find all sorts of solutions, some of which may be obviously appropriate and good, and others which you will need to take more risk on. The whole definition of the poorly-defined problem, though, indicates that you don’t really know what you want until you see it.

You need a team that’ll produce the iPod, for poorly-defined problems. And that takes experience-diversity.

Consider How Well-Defined a Problem is When Building Teams

Build on My Strengths and on My Peoples’ Strengths

Everybody has a strength. Probably more than one. We are better-employed when we use our strengths. When possible, improving your weaknesses can make you a more effective individual… But we already possess our strengths and can put them to work now.

Build on My Strengths and on My Peoples’ Strengths

Know your peoples’ strengths and put those strengths to work. Build teams with a diversity of strengths. When a task lines up with an individual’s strengths, put them on that task.

It’s just fun and feels good to get to use your strength. It feels like someone hit the easy button. We have enough things to do that we can’t always be working on our weaknesses – maybe we can’t hardly ever work on our weaknesses. If tasked to our strengths, we’ll do the things that matter to the organization and we’ll do them efficiently.

Probably everyone who works for me will have something they do better than me. Some strength I cannot match. Use that! As a leader I need to delegate all tasks that I don’t have to do myself. Delegate them to the folks that are better at those tasks than I am.

Build on My Strengths and on My Peoples’ Strengths

This one is kind-of a no-brainer. But often (at least in the military) we spend a lot of time working on our weaknesses – putting ourselves in situations that make us uncomfortable so we get better at those weaknesses. Making ourselves more general. I think that makes us stronger as individuals, and that’s great.

But it’s a hard way to work. I need to remember to press that easy button for my folks more often. Develop them strategically – look for those opportunities also… But in everyday tasks look for that easy button.

Mastermind Meetings

When I was flight commander, supervising a group of fellow nerds with nerd jobs, I spent almost all of my time on the administrative requirements. They needed me to do the boss stuff – that was my official position!

I really wanted to do the nerd stuff though. It’s more fun, it’s my strength, and I’ve got more experience with it… I’ll admit that as the boss I had input into many nerdy problems, and having that was rewarding.

These nerds had issues holding them back, and I had problems that could use nerd solutions that I hadn’t clearly identified (or for which I hadn’t identified someone to do the work). Putting all the problem solvers together with the problems has a ton of value, and brainstorm-like meetings can help solve that.

It doesn’t necessarily get me any time to work the nerd issues though – to exercise that part of my personality.

By the way, the type of nerd problem I’m talking about is cyber-related – that’s my field so I think I can call us all nerds safely.

Some talk about “mastermind meetings” or “evil genius meetings” – getting all the nerds together to talk about and solve their issues, usually at the tactical or operational issue. This isn’t regularly something the commander hops-in on, it’s an opportunity for the technical experts to sit around and solve problems over a beer.

I’m a technical expert too though!

I need to make sure I hold mastermind meetings with the types of nerd I resonate with. I need to make sure technical experts in the other fields I supervise also get together for their own mastermind meetings… I can set these expectations as the boss by finding the leaders in these groups and empowering them with time and support.

I’ll need to make sure rank and position are left at the door though. Free-flow of ideas is critical to this type of session.

Participate in Mastermind Meetings with my Top Nerds