How to Craft Winning Pitches By Thinking Like An Attorney

The nitty-gritty of how an attorney crafted an award-winning pitch at IBM’s Cognitive Builder Faire.

In my eyes, pitching a product at a hackathon is really just arguing that that product is “guilty” of being the best solution to the hackathon’s challenge. As an attorney, I am well-versed in the way that law schools across the United States train attorneys to argue, known as “IRAC’ing” (described below). By adapting IRAC’ing from analyzing laws to analyzing hackathon judging criteria, my pitch earned my team 2nd place at IBM’s Cognitive Builder Faire.

How to Think Like An Attorney

How to “IRAC”

Across the United States, law schools teach future attorneys to argue by identifying the Issue, identifying the Rule, Analyzing how the rule applies to the facts (also known as “Applying the facts to the rule”), and Concluding. As applied to Criminal Law, here’s how to IRAC:

Issue: What charge is the defendant facing?

Rule: The law the defendant is charged with having broken.

Analysis: What did the defendant do that lead to being charged with breaking a law?

Conclusion: Explicitly explain why the defendant’s actions broke the law.

Thinking this way is often referred to as “IRAC’ing.”

Using IRAC to Craft a Pitch

IRAC’ing is really just a way to map out an argument. At a hackathon, or when pitching to investors, your argument might look something like this:

Issue: Which hackathon challenge are you solving?

Rule: What criteria are you being judged on?

Analysis: How does your product meet the judging criteria while solving the hackathon challenge?

Conclusion: Explicitly tell your judges that, because your solution meets the judging criteria, you have solved the hackathon challenge.

Issue Spotting

How to Issue Spot

As an example for how this works in law, imagine you are studying to be an attorney and you are given the following (very simplified) set of facts:

Charlie was walking home from shopping, carrying a shopping bag, when Andy ran up to Charlie, pulled out a gun, and said “I demand you give me your shopping bag! If you don’t, I’m going to shoot you!” Andy then grabbed the bag from Charlie’s hand, and Andy left with the bag and made it to the safe house before the police were able to track down Andy.

Issue spotting is tightly connected to knowledge of the relevant laws, and identifying the issue first versus identifying the law first can often be a chicken-and-egg situation. In this case, you would know that these facts closely align with the crime of robbery, so you would identify the issue to be “did Andy rob Charlie?”

Issue Spotting with Hackathon Challenges

When it comes to pitching ideas, your product/project/company is the set of facts. The simplest form of your issue is “is my idea a winning idea?” Of course it is! But most hackathons have challenges or themes, so rather than proving “my idea is a winning idea,” it makes more sense to spot the challenge that most closely aligns with the product your team built over the course of the hackathon. Also, at one point during my pitch drafting, one of my teammates pointed out that pitches are often crafted to state a problem and then state a solution which clearly communicates the pitched product as the solution.

My team built a rapping chatbot, which we named “Kanye Watson,” so we decided that the most relevant challenge was “Community Creativity: How can you help artists to build communities and promote their art?” Rephrased, my issue became “Does Kanye Watson helps artists to build communities and promote their art?”

My team and I decided that the “problem” was that the “dramatic increase of computing power in the world is sending scientific progress into hyperspeed, yet the arts are withering and dying,” (slide 2) and that Kanye Watson was the solution to this problem.

Next, I needed a rule so that I would have steps to follow to prove that Kanye Watson would help artists to build communities and promote their art, if lots and lots of people were to use the rapping chatbot.


How Rules Work in IRAC’ing

Rules provide steps for you to take to prove what you are proving. For a prosecutor (or a law student) to prove that Andy robbed Charlie, that attorney must prove that Andy’s actions line up with the elements of the crime of robbery. For instance, in the State of California, robbery is codified in Penal Code 211 PC, and is typically taught as if it were broken out into 5 elements:

Robbery is

  1. the taking
  2. of someone else’s personal property
  3. from that person’s person or presence
  4. by force or threats of immediate death or physical injury
  5. with the intent to permanently deprive.

For Andy to be guilty of robbery, Andy must have done things that line up with each of the above elements of robbery. There are also “mitigating factors,” which are ways to reduce the severity of the punishment if a defendant is found guilty of the above 5 components. The mitigating factors include things like whether a defendant shows remorse, whether a defendant has a difficult personal history, etc.

Using Judging Criteria for “Rules”

At a hackathon, the equivalent to the rules of law in a courtroom is the criteria by which the judges are judging you. At IBM’s Cognitive Builder Faire, the judging criteria were:

  1. Applicability/Business/Societal Value — 25%
     2. Originality/Novelty — 15%
     3. Technical Strength of Solution — 35%
     4. Use of Educational Material — 15%
     5. Quality of Presentation — 10%

There were also criteria for reducing an overall score, known as “penalties,” which were comparable to the notion of mitigating factors in criminal law:

  1. Using technology / libraries that were not disclosed before judging.
  2. Checking code/workbooks into GitHub after the deadline.


How Analysis works in IRAC’ing

Analysis is also known as “application.” Essentially, you’re just applying your facts to the steps laid out in the rule. For our facts for criminal robbery, the analysis would look something like this:

  1. Andy committed a taking because Andy grabbed the bag from Charlie’s hand and left with the bag.
  2. The bag was someone else’s personal property because the shopping bag belonged to Charlie, not Andy.
  3. Andy took the bag from someone else’s person or presence because Andy took the bag from Charlie’s hand.
  4. Andy took the property by force or threats of immediate death or physical injury because Andy demanded Charlie give Andy the bag or else Andy would shoot Charlie.
  5. Andy intended to permanently deprive Charlie of the shopping bag because Andy left with the bag and went to a safe house.

Mitigating Factors? None.

Analyzing How Your Product Satisfies Judging Criteria

In essence, I needed to prove that my team’s rapping chatbot was “guilty” of helping artists to build communities and promote their art by proving that Kanye Watson had significant Applicability/Business/Societal Value, was original/novel, was a technically strong solution, used educational material that we had learned during the Cognitive Builder Faire, all while giving a quality presentation.

Ultimately, the analysis looked something like this:

  1. Applicability/Business/Societal Value: Kanye Watson has high societal value because Kanye Watson enables people who do not consider themselves artists to collaborate with their favorite artists by using data and AI.
  2. Originality/Novelty: Kanye Watson is highly original because it is the very first rapping chatbot.
  3. Technical Strength of Solution: Kanye Watson is a technically strong solution because it was built using multiple technologies, including a custom 6D algorithm.
  4. Use of Educational Material: Kanye Watson uses educational material from the IBM Cognitive Builder Faire because it is powered by Watson Natural Language Understanding API, which attendees were taught how to use during the Cognitive Builder Faire.
  5. Quality of Presentation: #Obvi my presentation is #KillingIt (I genuinely considered saying something like this during the pitch, but I bit my tongue. Sometimes my lawyer brain wants to take things a little too literally. Instead, I let the quality of my presentation speak for itself)


  1. Using technology / libraries that were not disclosed before judging: My team didn’t disclose the contents of our technology before the judging, so there was potential for us to be penalized based on that.
  2. Checking code/workbooks into GitHub after the deadline: My team didn’t check code into GitHub, so there was potential for us to be penalized based on that.


How Conclusions work in IRAC

Think closing statements on Law & Order, and you’ve got the jist of concluding in IRAC:

“You, the jury, have a responsibility to find Andy guilty of robbery. Andy committed robbery because Andy committed actions that satisfy all five elements of robbery, and none of Andy’s actions or history support any mitigating defenses. Andy grabbed the bag from Charlie’s hand and left with the bag; that shopping bag belonged to someone else, Charlie; Andy demanded Charlie give Andy the bag or else Andy would shoot Charlie; and Andy left with the bag and went to a safe house. Based on the evidence, the State of California urges you to find Andy guilty of robbery.”

Concluding that Your Hackathon Product #WinsTheHackathon

Unlike a jury, who has to listen to your argument for days over the course of a trial, your entire hackathon pitch is over in 3–5 minutes. Because of the huge difference in the amount of time, you don’t really need to remind judges of arguments that you made earlier during the conclusion. Instead, at hackathons, your product demo is really your conclusion. So make sure that your product demo evidences aspects of your pitch “argument.”

Most importantly, when it was time to deliver, I delivered my pitch with the same fervor as I would an opening argument in court, treating the audience as a fact-finder (they had to be engaged and they had to like what I was saying!) and the judges as, well, judges. Ultimately, the panel of judges was going to decide whether or not I successfully defended Kanye Watson as a solution to helping artists build communities and promote their art.

This post is part of my post Crafting a Winning Pitch About a Rapping Chatbot, originally published on my blog, Tech Talk Translated, on July 4, 2017. You can see the actual slides I used in my pitch in my Medium post Crafting a Winning Pitch About a Rapping Chatbot (Includes Actual Pitch Slides!).

Like what you read? Give Lauren Harriman a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.