Thought waves on seed venture

Demos help us experience the product in a way that's not lines of code or marketing bullet points or concepts.

To help us unpack why demos are an essential craft that needs to be honed in start-ups, we talked to four product legends to get their insights, thoughts, and opinions.

• Sherif Mansour: Distinguished Product Manager at Atlassian.
• Mindy Eiermann: Director of Product Management at Intuit.
• Jens Schumacher: Chief Product Officer at Search.io.
• Somya Kapoor: CEO & Co-Founder at TheLoops.

All were kind enough to share their take on The Art of the Demo.

Demos simulate the customer experience

When we asked why they think demos are important, Jens and Somya both spoke of demos as breathing life into projects. Jens believes they make the abstract tangible and provide an opportunity to clearly demonstrate how specific problems are solved. Somya thinks of demos as "windows into the vision", where you distil the idea potential and capture the audience.

Sherif and Mindy agreed. For Sherif, the demo audience simulates the customer, so the presenter has to be very aware of the customer experience during delivery, more than with other modes of presentation. He added that "it’s much more effective to have a meaningful discussion and make prioritisation decisions when you use your demo as a shared language, rather than using a bunch of text and bullet points". Demos simulate reality, whereas bullet points abstract it.

Demos are an opportunity to tell a story

Mindy puts it beautifully when she says that "giving a demo is so much more than showing someone your product. It's about telling a story and doing so in a way that marries customer insights, data, and a product experience to take your audience on the journey." We love this and we wholeheartedly agree.

Demos are a story. A very important part of your product story. They allow you to empathise with customers, understand their challenges and see how to solve their problems. You can't get this effect with a slide deck. Empathy is built when you can put yourself in the shoes of the customer. As Mindy says, "the more effective you can be with creating that empathy and understanding, the more likely you will be to get the support you need to be successful".

Three key demo use cases

1. Transfer knowledge to internal teams
   Demos show how a customer problem has been solved and explain the steps taken to arrive at the solution. This is valuable knowledge that can be used to impact other customer problems, and enable marketing and support teams to explain features more clearly to customers.
2. Drive customer sales
   Demos are a visual and engaging way for the target audience to understand a feature, a whole product and the experience they will receive. The old adage of 'show don't tell' applies here, because it enables the customer to 'see themselves' using a product, achieving a task, solving a problem. Demos create a connection which (hopefully) leads to sales.
3. Show investors your value
   Demos are essential for telling the success story of your product, what it does now, what it can do soon, and where it fits in a customer's life and the market. Investors look for ideas that loudly communicate potential, have a clear purpose and reflect a better reality. Investors want to put their money in a product they can see, not a bullet list of nebulous benefits.

‍

Our experts share their demo stories

Sherif's demo story

Sometimes demos reveal something that has not been noticed before. Sherif recalls when the team building software for mobile showed how they solved a particular customer problem. But only on mobile. The same problem existed for desktop users, but the solution approach had not been discussed with the desktop engineers. Sherif remembers that "the demo highlighted that we were letting our internal team structures influence the customer experience." The demo showed the need for better information sharing and highlighted a creeping silo problem between teams.

Mindy's demo story

Never underestimate the hunger of a demo audience. Mindy tells us how she was preparing for a huge public product launch and the engineer who was running the demo did a rehearsal with her beforehand. She thought it might be too detailed and make people bored. "Boy, I was wrong" she reflects. "The accountants in the audience were sitting on the edge of their seats that night. They wanted all the detail so that they could understand exactly what impact the new experience would have for them and their firm."

Jen's demo story

You can talk it up all you want, but you've got to show people how things work. "In a world where AI has become a buzzword appearing on every marketing website, it was important for Search.io to demonstrate how easy and practical it is to implement a personalised search experience". Through demo storytelling, Search.io could highlight the personalisation and focus on the "benefit to customers". Jens believes their simple but effective demo has closed the majority of customer deals.

Somya's demo story

During our Seed round raise the product was nascent, but our vision was crisp. While it wasn't quite fake it, till you make it, the demo we shared with Tidal and other investors was expressive enough to convey a rich end to end experience. It communicated the land value proposition, the hook for our target audience and even hinted at our future potential. Akin to Jens, Somya was able to successfully complete her raise in quick time as the demo was a key part of investor conviction.

Expert tips

There is always a before and after

You can demo anything, even if it’s an API change or a bug fix. Make sure to start with the problem and why it was worth solving and make sure everyone is aligned on why the solution is designed in that way.

- Sherif Mansour

Tell a story that people can relate to

Don't just run through the motion and explain what's happening on screen. Focus your energy on a couple of key highlights that you want the viewer to remember.

- Jens Schumacher

KISS - Keep it simple, please!

Not more than one minute and engage the audience every 30-45 seconds - especially in the zoom world or else you are just another screen they are looking at for hours.

- Somya Kapoor

Know your audience

When demoing to senior stakeholders, spend less time on the nitty-gritty and more time on the customer insights, data, and the story. This will help the audience connect the work. For sales team type demos, focus on the customer benefits and concerns to help guide those conversations.

- Mindy Eiermann

In conclusion

If there is a downside to demos, we haven't found one. Demos take concepts and make them real for your teams, your customers, and the people you want to draw in as investors. Keep them short, purposeful and relevant for your audience, and you can't go wrong.

Big thanks to Charlotte Jiang for helping me draft this post and to all our demo experts featured.

The art of the demo is an essential craft that needs to be honed in start-ups as its used in so many high-impact moments. It could be a founder pitch, planning a new feature, creating a new product horizon or (re)defining your vision to stakeholders. But there is a big difference between going through the motions of demoing your product versus developing a demo muscle that forms the cultural identity of your company.

Demos are the higher-order bit of story-telling for startups. It is a compass for authenticity and its value cannot be underestimated. A great demo is priceless.

During my time at Atlassian we productised many of our operations or rituals. The result was the Atlassian Playbook. My contribution was co-creating the Project Poster and Demo Trust. We developed these plays (and many more) as scaffolding to scale during a period of hyper growth for the company.

The plays gave us a common language when working on feature proposals, new initiatives and offered a dedicated forum to refine and improve the product experience via demos. They served as guardrails for our freshly minted teams.

However these plays were not optimised for startups that are running fast and could benefit from a more streamlined approach. So I wanted to provide a guide that's a short and sweeter remix optimised for seed stage companies. It contains the essentials that will illuminate a path to a solid demo.

The best part is there are opportunities to demo around every corner. Each moment is a chance to build this muscle and make it a part of your company culture.

Overview

One of my formative experiences as a founder was early on in my first startup. I showed a rough demo of a shortcut feature at a conference and I unexpectedly heard ooh's and ahh's from the crowd. Boy did it give me conviction about our direction. It was validation of how powerful a demo is for storytelling and we were acquired less than 3 years later. But what was it about that demo that cut through to make a difference?

In his book The Macintosh Way, Guy Kawasaki wrote a chapter called “How to Give Good Demo,” where Kawasaki suggests that good demos should be short, simple, sweet, swift, and substantial, and that starting with a script that satisfies these requirements is the foundation for success.

This advice is still valuable today, but I'm going to argue that above all it needs to be authentic. Why? Because often you are continually tuning different aspects of your demo and so it's okay to compromise on some of these points early on. But when you give an authentic demo you really:

1. Focus on what matters to your audience and in turn your company. We talked about drift in the Connected Roadmap. An authentic demo is validated by your users, stakeholders and teams and is a practical tool in finding and retaining product-market fit.
2. Expedite how you communicate value through a shared understanding. How many times have your users or stakeholders had a different thought bubble about how they interpreted your explanation or email? A demo is a tangible way to share an idea, reduce ambiguity and get alignment.
3. Fast-track team velocity as you cut to the essence of intent. If you are doing the first two things well, in my experience it also unblocks the typical hurdles in reaching stakeholder alignment and decision-making. While this may not be as big a deal as a seed stage company, it sure as hell gets more difficult as you scale up. It empowers the team to make difficult trade off decisions whilst holding true to the core idea.

How to get started

I recently finished reading Creative Selection by Ken Kocienda about his takeaways as a software engineer and designer at Apple in the early years. One of the core concepts in the book is they often used demos, dog-fooding and continual refinement as tangible expressions of ideas from creators and stakeholders and let natural selection decide which would thrive or go extinct. While this book focuses on an insiders' experience at Apple, this culture was certainly not exclusive to Apple. I had similar experiences as a leader in prior companies.

Similarly you have opportunity to integrate the practice of demos neatly into your existing learn, build, measure cycles. The steps below are a guide in developing that muscle 💪

Demos should fit neatly into your development lifecycle

Define your hypothesis

Conduct preliminary research: Clearly articulate why you are doing this.

What problem are we solving?

Impact of the problem?

What data to we have to support our thesis?

Expected Outcomes

Explore your assumptions: Document what you know, don't know and must achieve.

What additional data do we need to obtain?

How do we judge success? Quantitative metrics & qualitative observations.

Possible solutions:

• List all approaches in very briefs paragraphs.
• Select best approach and build a prototyped demo (ideally code, but early stages can be as scrappy as you need to convey the ingredients below).
  

Validate your hypothesis

Synthesise the demo: Create a compelling narrative for your demo.

• Scene setting: Target audience, context & motivation which could be framed as a Job To Be Done (JTBD), epic level user story etc.
• Problem / complication: Describe the pain points that eventually translate to some form of better, faster, cheaper; always make it familiar and relatable.
• Intro solution: Talk about the why; if it's faster, make it about how you'll save time, if it's cheaper, talk about how you'll save money (this is ok, but hopefully not your only benefit), if it's better, show me how I'll enjoy doing it, at least more than compared to today.
• How it works: This is the core part of the demo and communicates the workflow, interaction or journey the user is likely to experience.
• Highlight and delight: Touch on the key aspects of the flow, and between each highlight drop-in a delighter ✨ that is an aha moment or better yet, mind-blowing 🤯
• End scene (optional): Close with summary with respect to their Return on Investment (ROI), or likely outcomes by the numbers.

When developing your demo DNA ideally embody your product and customer facing teams such that there is a shared accountability of authenticity. In other words, call bullshit when a demo does not fulfil the promise of your mission or what you are setting out to do in your regular planning cycles. But always make sure you do it thoughtfully.

Demo Formats

A demo can take many forms such as live presentation, video, or storyboard. They each have their purpose and can be useful, particularly as organisations accept flexible work arrangements. Practical examples I've adopted in the past:

• Live: When you want an active way to develop your shared accountability of your demo authenticity, there is nothing like presenting live. This is generally face to face for workshops, design sparring, but perfectly fine over video screen-sharing.
• Video: This provide a passive way to develop a culture of demos and sharing with teams to assist distributed teams where timezone or async check-ins helps flexibility. Videos are easy to create and really force you to consider the script, flow and delivery. Silent demos (no talk track) can also work if the flow is self-explanatory. I would suggest titles and spotlights to assist the viewer.
• Storyboard: For teasing out conviction of early stage concepts, you can't beat a storyboard. The key frames help you structure their thoughts into bite-sized ideas before investing any engineering or other effort. Yes, anyone is capable of drawing shapes and stick figures!

Demoing API's

But hold the fort! I hear you hark "I have an API or platform that does not have a traditional user interface". Fear not, all of this is still very much applicable. In fact you should be even more invested in a demo. But the difference is about expressing the possibilities and/or seeding with one or more examples to inspire your audience which is often a developer. In these cases I tend to lean on great documentation, live samples and lowering the barrier to getting started.

• Stripe: Probably the most referenced example and for good reason. The simplicity, quality and comprehensive coverage for their developer audience is incredible and it all started with helping developers quickly transact using their recognisable checkout experience.
• Search.io: How do you demo a search engine that specialises in e-commerce? Well you provide a complete "kitchen sink visual demo, to a fictitious store where a dev can kick the tyres.
• FrankieOne: KYC and AML got a little more exciting by allowing an institution to understand how they might incorporate RegTech into their existing apps, backend, workflows.

Inspirational Examples

Here are some inspirational demos or experiences that invoke some or all of the ingredients we seek in a great demo and loosely follow the narrative flow above:

• Superhuman: Well known for their white-glove onboarding demo via their customer success that truly make you wonder where has this email client been all my life. Best to actually do the 1:1 onboarding to experience it for yourself.
• MmHmm: Phil Libin makes a really personable video that is just down to earth and really expresses all the frustrations we've been having with video calls while in lockdown or potentially as the new norm. So why should we settle?
• Descript: This may be a meta example. While it is a very orchestrated marketing video, it still hits all key points in a great demo with some really next level experiences for making video editing easier. Descript could even be your next tool for making awesome demos.

Demo outcomes

As founders and product leaders, you strive to tell meaningful stories that are authentic. This virtue must shine on in your demos too. If you are nailing all the points above you should be achieving the following outcomes:

• Validation: You are always experimenting, so every learn, build, measure iteration is a chance to validate your thesis and assumptions.
• Excitement: Acknowledging user pain points and motivations in every story you tell creates an emotional connection to your audience.
• Alignment: Each time you share your story, you refine through validation, replace scepticism for excitement and tie back to your purpose and vision.

The sum of these parts results in conviction for you and potential investors. In short it represents a path to unlock funding and provides a succinct and tangible communication tool.

Proactively developing your demo DNA will benefit you and your startup as it is a powerful mechanism to cut through so many things that often get lost in translation. Think of it as a vital part of your founder or leadership arsenal.

An authentic demo can be truly game-changing. After all, isn't that what we are all striving for?

Roadmaps serve as a powerful communications tool for product leaders.

They aim to:

1. Build a shared understanding between stakeholders
2. Show areas of investment
3. Bridge strategy to tactics

When you think about it, that’s a lot of stuff to put into a single visual. Making a stellar roadmap to solve all these problems creates a concentration of pressure. As a result, we see many teams fumble while trying to tick all these boxes.

In a world where there is growing specialization in skills, techniques, and in turn software, why are we still trying to squeeze all this information into one tool?

Recently, I had the pleasure of (virtually) meeting Marty Cagan from the Silicon Valley Product Group and author of the seminal product management book, Inspired. One of his key messages during a Q&A session was that product teams waste so much time developing and estimating feature roadmaps, when they should be focused on build, measure, learn cycles. That is, focus on product outcomes, their priority, and buy time until you have data-informed tactics.

This does a couple of things:

1. You learn what really matters to users faster
2. You avoid unwanted feature bloat

You can read more about Marty’s thoughts on this here and here.

Bottom line: the intent of a feature in a roadmap can be interpreted subjectively, and as a result we have seen teams drift from their original goal during execution. Whereas an outcome on a roadmap is unambiguous, offering a constant reminder of your desired goal throughout your delivery cycle.

Examples of drift range from:

• Anecdotal thesis: starting a project without success metrics
• Product bloat : having clear measures for success, but deviating due to over investment and sheer momentum
• Goal posts: feature scope shifts yet the measures unchanged
• Never ending story: delivery time extends with no recognition of the original desired result and in turn checks and balances for incremental delivery

We spend a lot of time reviewing product roadmaps with our portfolio companies at Tidal and many more in review sessions over my lifetime a product leader. We tend to run into this issue consistently. So we created a practical guide on developing a connected roadmap that leans on complementary artefacts to address the goals above.

Overview

Here is a visual map of how we will progressively leverage a set of common artefacts to achieve a connected roadmap:

Goals pre-flight check

Before getting started on a roadmap, we need some guidance from leadership. Your company goals form this guidance. We will use the OKR (Objectives & Key Results) format to frame them with a business lens.

This is what it might look like:

Use this checklist to inform your roadmap:

• Focus Areas: Does the OKR call out your team(s) as a dependency to achieve the goal? We recommend defining Focus Areas per OKR to set expectations for accountability and provides an opportunity to have a conversation about resourcing.
• Focused Key Result: Does each Objective have one primary Key Result? A secondary Key Result should only be used to help qualify the effort. This helps reduce unambiguity and will align behavior. An example of a primary key result would be improving sales efficiency from $x to $y, with a complementary qualifying objective that maintains your conversion rate at a floor of z%.
• Ordered Objectives: Are the OKRs an ordered list? This forces leadership to prioritize the bets the company is taking; just like you need to prioritize your roadmap. Guaranteed these priorities will be tested throughout the time span and it’s best to understand those trade-offs early.

Finally, are the company OKRs you are accountable for grounded in rational optimism? You want to be ambitious, but it needs to be coupled with a reality check that considers cadence, dependencies, and the timespan for achieving the result. While this is not specific input into building a roadmap, it's worth asking if you are set up for success?

Posing the checklist and your own situational questions helps develop a shared understanding with stakeholders and is half of the solution for aligning on value.

Now that you have tightened up the business OKRs, let's connect them to your product roadmap.

Outcomes not features

The fundamental challenge with most feature-based roadmaps is they are used to convey product strategy to stakeholders but are rarely self-explanatory. They require a talk track to explain how tactics (features) ladder up to strategy (outcomes), rather than stating the strategy itself and making it accessible. This way, your feature doesn't get in the way of your outcome. If your feature fails the goal, you can pivot without changing your high-level roadmap.

Outcome-oriented roadmaps help you defer and switch tactics while maintaining the original intent that stakeholders are aligned on:

Feature roadmap

• Improved onboarding (frames it from the user's lens; push this down one level)
• Establish a baseline conversion rate of at least 4%

versus

Outcomes roadmap

• Increase unassisted user adoption (frames it from the product lens)
• Establish baseline conversion rate of at least 4%

This is what it might look like:

Here are the ways to convert typical roadmap elements into an outcome-oriented roadmap:

1. Swimlanes: Use the business OKRs that require a direct contribution from product teams. Traditionally you would use themes, but they only serve as a narrative to your feature grouping rather than being an effective way to remind stakeholders how product strategy connects to your business objectives.
2. Timeline: I recommend using quarterly intervals if you are having some delivery cadence challenges or you are a time-driven organisation; alternatively Now, Next, Later may provide a more flexible structure for fluid development.
3. Bars: Cards should be represented as outcomes instead of features. Leave features for your Scrum or Kanban boards to build more conviction in your tactics through rapid iteration.
4. Milestones: this is an optional element, but should tie to a series of major stages

You may be thinking an outcome-oriented roadmap lacks the depth of the feature roadmap. But what you lose in detail you gain in clarity of purpose. It is the other half of the solution for aligning on value and illustrates how you intend to prioritise value delivery.

Now that you have expressed your product strategy using outcomes, let’s connect your strategic outcomes to your feature tactics.

Make it epic

In agile development, epics encapsulate a set of related stories. Often a few epics may be required to achieve a desired outcome through gradual iterations. The simple use of a progress bar within each (outcome) bar connects strategy to tactical delivery. It also enables stakeholders to track progress in delivering user value, associated with the outcome, and finally the business OKRs.

This is what it might look like:

We do not prescribe a specific agile methodology. That is very much a team decision. However techniques like User Story Mapping or Jobs to be Done are a useful methods in curating what actually gets on your backlog.

The mindset of having a groomed epic backlog should be strong opinions, loosely held. Each epic merely represents a way to capture your thesis of the user value impact for a given feature; and why it is a suitable leading indicator to the outcome's lagging indicator in your roadmap.

Here are ways to tweak a typical Scrum or Kanban board elements to connect your roadmap:

1. Columns: our recommendation is to capture select stages of your delivery cycle per column. Consider this as a more precise snapshot of a feature's delivery using a common language of your product team. For example we have seen teams track Backlog, Discovery, Build, Test, Beta, GA and added steps in between to suit their path to production. The use of a time-scale is less relevant at this level and you are better off aligning the team to your roadmap for time.
2. Cards: are simply the epics or stories/tasks that progress through each of your stages. Again it's important to iterate that having a rapid test & learn culture means not all things get to production. Being deliberate about this will help you forge a better product.
3. Tags: using tags (aka labels) helps connect an epic to an outcome. By doing this it should control the progress bar on each outcome's bar on your roadmap.

By tuning your board elements this way, you have connected to your roadmap, and in turn the company goals. Congratulations, time to celebrate.

Adopting a connected roadmap may resolve unwanted pressure by allowing each artefact to have a clear purpose. Everyone in the organisation should have more clarity as they can cascade up or down through each view and see how value is aligned, prioritised and consistently defined at each level.

Let’s recap the benefits of using a connected roadmap:

• You have a self-serve document that better communicates your strategy.
• Reducing communication friction allows you to spend more quality time debating the things that matter.
• Deferring tactics till slightly later in the planning cycle reduces feature bloat and speeds up your path to validating if a feature will actually deliver on a given outcome.

Thanks to Tash, Andrea, Georgie, teams at Bonjoro, Shippit, and Secure Code Warrior for contributing and reading drafts of this article.