Stop Pitching. Start Collaborating!
⚡TLTR; In this article, I contemplate my 20 years of professional experience. To better understand why pitching as a “one-directional communication” method can lead to unnecessary problems in product development and could be your last showstopper for a more sustainable product process. In most cases, it is more helpful to use “bidirectional communication” methods instead, which allows you to communicate in two directions and transform boring presentations into meaningful conversations. This, in turn, will help you eliminate unnecessary friction from your product design process, allowing you to build more trust, speed, and reliability over time.
Feel free to also check out the Learning Loop Meetup video recording featuring some insides of several industry professionals, including my own take on why and how we should stop pitching in product orgs: (5) Presenting and articulating design decisions — Tom Greever, David Zerbe & Joachim Blicher — YouTube
Have you ever wondered why your finished product often has little in common with the initial idea? For over 20 years, I’ve seen successful presentations or so-called pitches concluded in disaster during the later implementation phase. Whether big customer-, project-, or internal presentations. The final outcome is rarely comparable to the former presentation. In this article, I want to give you a glimpse into my experiences so that you can achieve better results in the future without getting hung up in reoccurring discussions.
For the first 10 years of my professional career, pitching was unavoidable and integral to my daily work. For sure, the thought has crossed my mind that the final release was just a pale imitation of what was pitched in the first place. Still, I never questioned it — I even convinced myself that it must have been other external factors that coursed this pale imitation to emerge. After all, my team always delivered and conceptualized everything to the smallest detail so anyone could implement it, right?
It wasn’t until years later when I eventually transitioned from “Art Director Digital & Concept” at Jung von Matt to “Design Manager” at Spreadshirt, that I realized my miss conception. However, after a while, in my new role as Design Manager, responsible for oversight of the entire process, I ultimately realized that I had several fundamental flaws in my previous way of thought, including team leadership, process management & handoffs which I learned to overcome for the last 10 years.
The Pitch
Before I digress too much into the details, it is essential to understand the pitch situation itself to learn about the pivotal roles.
First and foremost, a pitch always has a clear objective, a time limit, and a distribution of roles. In most cases, there is the presenter on one side and the decision-makers or listeners on the other. Based on your pitch, these then decide on the project’s further course. In short, your task as the presenter is to convince the others that the approach presented is good enough to move forward in the process.
The greatest weakness of the pitch lies in its nature. As you might already have concluded from my description, each participant in the presentation has a role to fulfill, which comes with their individual challenges and requirements. Simply put, your role as the presenter is to persuade the participants to believe that whatever you present is right and should be allowed to proceed to the next phase. Failure is usually avoided, as it would entail an enormous organizational and resource burden to the project, budget, and the project team.
“Your role as the presenter is to persuade the participants to believe that whatever you present is right and superior to what they already have.”
On the other hand, the listeners or decision-makers also have a role to play within the scenario, either as gatekeepers or quality assurance. This inevitably puts you in an already tough situation, so you’ll need to invest much energy in preparing the pitch and your persuasion during the presentation so that your work and that of your team are not in vain. Especially within a product organization, this can inevitably lead to a social contract where both sides know that rejecting the pitch will result in significant additional effort. Questioning the presented artifact could influence the release and the roadmap planning — in doubt, it will be passed and handed over.
Due to his structure, the pitch only allows for a one-way communication, which opens the door for each of the participants to interpret your message and visuals based on their individual emotions, experiences, and knowledge — Therefore, missing the chance for a bidirectional communication which could lead to more relevant conversations to gather valuable insights.
Or, in short: “you take the participants hostage and release them only when the pitch idea convinces them”.
“Rule of Thumb: Everyone says yes — if you annoy them enough”
False Positive
Due to the nature of the pitch, it often leads to a so-called “false positive”. After the pitch, your team might feel like everything went well. But in reality, only the fancy presentation slides with all their superficial insights have convinced people without looking at them in detail or sharing valuable insights. This leads to recurring questions and unnecessary clarifications in the further implementation process, which dilutes the final result over time until nothing is left of the once great idea and frustration among the parties involved.
I experienced this myself, and I’m delighted that it looks different nowadays. But unfortunately, there are still exceptions in which my company gets only booked for a segment of the process and therefore loses valuable insights and influence over the overall result, leading to a degeneration of the initial vivid ideas.
The Problem
When we think of a typical product organization, three major departments usually come to mind. Those could be the business department (management, sales, vision), the product department (design, research), and the dev department (implementation). However, if you look closer, islands (silos) start to emerge. The nature of an island is that each has its own culture, structure, processes, and unwritten rules, which the inhabitants are rarely aware of.
Suppose we now want to transport information from one island to another. In that case, we need a medium for transmission, like a boat. So, we load the boat with as much as possible to transport the necessary information and materials. But, of course, the space on the bot is limited, forcing us to screen out everything that is, at first glance, not mission-critical for the further project. Unfortunately, if we even notice, we only find out which necessary information we had to leave behind after the boat has been deployed and the cargo has been processed. We’re losing the message bit by bit as it continues. Did you ever play the telephone game as a child? How many “handoffs” did it take before the massage fell apart and transformed into something else?
“Rule of thumb, each handoff leaves behind approximately 50% of the knowledge we intend to transfer!”😲
Nevertheless, we certainly see that our project has changed significantly during the product process. Changes had to be made repeatedly, some justified, and others unnecessary, as necessary information was unavailable during the critical debates and was thus adjusted frequently within recurring discussions.
The Utopia
If you imagine the perfect product process, it will look like a loop without friction or knowledge gaps through handoffs. A process where everyone knows what to do and when with all the information at hand during the process, to understand what is being built and why. This would allow you and your team to build up more speed over time, thus getting closer to the “Continuous Integration” ideal.
As soon as you have friction in your processes, you lose traction and thus prevent yourself and your team from getting into a flow state. Imagine The Flash ⚡ having to pause every few seconds? He would never reach the speed of light and thus never save the day. That would undoubtedly be pretty unappealing from an author’s and reader’s point of view. However, this happens to us as authors of our product design process, as we too often endure the status quo without questioning it from time to time as the hamster wheel keeps running.
“Without a presentation, all that is left is communication […]” — by Blair Enns
A Possible Solution
We want a process that allows us to operate without friction. The fundamental prerequisite for this is the courage to fail fast and the trust of the upper management. To act autonomously, the team needs to control the 4T’s (Time, Task, Team, Tools). Once we have that, nothing stands of our perfect product process. A first step towards this utopia could be the reduction of friction by strengthening bidirectional communication by reducing the time and effort previously consumed by presentations.
You can start the first experiment today by transforming your presentations into two-way conversations for two weeks, in which you work together to explore different opportunities and solutions — remember to discuss your experiment with others in the first place to keep the expectations clear and avoid disappointments.
In a later article, I will dive deeper into the setup and structuring of an initial entry-level product process. This allows you to establish a long-term functional product process, even if agile methodologies still sound like heresy in your environment.
Bonus: Never use a Pitch for Product Validation
Avoid pitching your ideas to potential users or stakeholders, as you may accidentally involve them in a “Social Contract” from which many interviewees can only escape through kind words. As a result, you may be unable to gather valuable insights to determine if your product, mockup, or concept even works in the first place. Instead, try to let your idea speak for itself and ensure that all the key roles are in place from scratch to build a shared understanding of what you want to build. For example, suppose you are in the pilot stages of product validation. In that case, you should avoid pitching altogether and opt for an indirect questioning strategy toward your potential audience. This will give you much more insight without accidentally trapping your counterpart in a Social Contract. Otherwise, you will only hear things like “I’m certainly interested,” “good idea,” “I would buy it”, and so on, without ever knowing if there is anything besides the charming words to please your ego.
Conclusion
A presentation can create unnecessary friction in your process and may lead to so-called “false positives” as well as unnecessarily recurring discussions, which can negatively influence the product result since the usual pitch scenario allows only a one-directional communication.
To ensure the quality of the product, you should instead rely on bidirectional communication methods like hands-on workshops. The void created by omitting presentations can be filled with smaller workshops to aggregate and retain knowledge within the project team. This enables you to ensure that everyone is on the same level and can contribute their valuable insights without friction, preventing unnecessary waste of resources overall. Experience shows that the more open design thinking approach can increase the chance of survival in the market without diluting the result.
In case you want to learn more about the topic. Feel free to reach out to me or check the following book recommendations: “The Mom Test,” “The Stop Pitching Manifesto,” “Lean UX” or “Pitch Anything.”
