Thought waves on seed venture

When they say that necessity is the mother of invention, it also means that when you want something invented, you have to invent it yourself. That’s how Bonjoro came about, according to Matt Barnett and Grant Dewar. 

Noticing the diminishing effectiveness of email campaigns to engage new customers and secure sales, they decided to hack something together from duct tape and blu-tac, and record personalised videos instead. 

“Hey [potential customer’s name], as you can see we’re here in sunny Sydney at the moment [shows Opera House backdrop], but we’re heading to London soon for [insert reason]. We’d love to meet up and chat about [the thing we can help with] as we have also done [that thing] for [other high profile customers] too. Give us a call. Byeeee. [Waves into camera from Manly ferry.]

- Dramatic reenactment of an early Bonjoro customer video

Then someone saw the idea and wanted to make videos for their customers too. Then another person wanted to integrate it with their CMS and their campaign software. Google became customers and so did Firefox. That’s how the product was born and since then there's been no looking back for Bonjoro.

Tidal meets Bonjoro

Tidal’s Grant McCarthy met Matt and was interested in Bonjoro early, when they were initially seeking Angel investors. By the time Bonjoro was ready for seed funding, the conversations between Grant and Matt had developed into a relationship, and Tidal came on board as an investor.

Matt says he “likes investors with a lot of energy and who can contribute to what we’re doing.” That’s why Tidal was a natural fit, because they had the right mindset, and it was “a relationship as well.” 

Tidal “understood our space” is how Matt puts it. “They understood our customer success space, the SaaS space, and the US market.” An alignment, he said, that was critical to their next stage of growth. Where other Australian VCs focus on the local market, Bonjoro was confident that Tidal had the experience and reach to support their US market growth from day one.

Wearing the founder hat and the Tidal hat

Matt points out how unusual this is among investors, saying “funds tend to approach things as a fund, but Wendell is able to approach things from different angles” due to his background and experience. He adds that “Tidal is willing to get their hands dirty and directly contribute to the success of each of their companies, more so than most funds I’ve seen.”

This has been Grant’s experience too, noting that Tidal has “got us through some strategy and ideation points where their product experience and expertise has been really invaluable, which is something I wasn't quite expecting.”

“Tidal is willing to get their hands dirty and directly contribute to the success of each of their companies, more so than most funds I’ve seen.”
- Matt Barnett, Bonjoro

How the engagement goes deep

Like many startups, Bonjoro faced the common founder challenge of juggling product growth with capital raising and business scaling. Matt describes this as “like climbing a hill and then you get to the top, but it's not the actual top, it's just the first peak. And you've got to put your pack on and start climbing again.” When asked how Tidal has helped climb some of those hills, both Matt and Grant had a ton of examples.

There’s support from tidal on multiple levels, according to Matt. On the business and management side, Tidal has helped with C-Suite, R&D recruitment and mentoring, developed and defined skill sets for senior positions, and supported the founders to prepare for and get the most from interactions with the board. 

On the product side, Wendell has dived into Bonjoro product activities, by chairing workshops with global teams, running product challenges and positioning pieces, and helping with strategy and roadmaps. 

Bonjoro says it’s unusual to receive such in-depth, tangible support from VC investors. But the benefits seem immeasurable.

Choosing between a safe plateau or rapid growth 

When it comes to choosing VC investors, Matt says “it's about being pushed as well.” This became vitally important as Bonjoro looked to their next big growth stage. They had just reached break even (congrats!) and it seemed like a good time to assess.

That’s when Tidal challenged them with a few big questions that would shift their thinking into a higher gear: How much do you need to raise next? How many hires do you need to make? In other words, how do you want to grow?

Through lengthy conversations, in-depth workshops and meetings, Tidal and the Bonjoro founders discussed whether Bonjoro should grow fast or steady, to hire across the year or all at once, spend a lot now or spread it out. It was a matter of staying on the break-even plateau or taking a risk and going for it! Matt observed that being able to have “this level of transparency builds great trust and understanding.” Ultimately, Bonjoro decided on the riskier move, but noted that “looking back we should have gone even faster!” 

Having decided on the speedy path, Tidal was right there to help shape Bonjoro’s challenging transition from product to platform, which would be a pivotal part of maturing their offering. “Workshops with the management team and Tidal helped crystallise the strategy into an actionable plan. The best attack plan.” Part of this included commercially aligning the planned value-adds going into the product, by revising the pricing and packaging model. This is always a risky area and can result in customer churn. By providing “feedback and education on the importance of packaging alongside actual pricing,” Tidal helped Bonjoro better target by segment and make revenue-improving changes. 

Never slack on advice

Bonjoro has noticed “a lot of other investors tend to be more hands-off.” They respond when you call on them, but they’re not part of the team. Tidal is different. They are “proactive and that’s what we look for, someone who can actively bring value.”

This is supposed to be a blog about the company Shippit, one of the first investments by Tidal (or the company that was to become Tidal) back in 2017. The two companies sort of grew up together.

I could have written at length about how they are revolutionizing the way shipping works in Australia and overseas and raising capital left and right, but when I interviewed the Shippit founders, I decided to focus on their magic partnership and the relationships that have helped them succeed. 

It’s hard not to reach for words like ‘bromance’ and ‘misterhood’ to describe the easy rapport and sentence-finishing communication that long-time friends and business partners Rob Hango-Zada and William On enjoy. And it doesn’t take a startup genius to realise that their relationship is a key ingredient of their success.

Relationshippit first

Great relationships seem to be at the centre of all Shippit’s growth success, from building rapport with customers, finding the right investors and employees, and realistically assessing the gaps and making the right call on how to scale up. 

Will says their approach to most things is “we don't know all the answers and our focus is to get the right people around us.” When applied to investors, Rob explains that “any investor coming in is a long term relationship; and we want to partner with people who are really invested in our company.” 

If the three most important things in an investor are “getting along on a personal level, having a solid understanding of the domain and people, being able to push us in terms of our thinking,” then Tidal is an ideal fit.

Grant McCarthy and Murray Bleach were Shippit’s first Tidal contacts. “Grant and Murray took a more US VC style of approach that added value beyond the checkbook.” This was important, according to Will, because having input about product, finance and deal flow meant that Tidal became part of the team. 

Co-investing in Series A with Aura Ventures, Grant was keen to participate. He has “a lot of knowledge around the last mile logistic space, understanding of where the market was going. He also really understood the macro themes of an open network two-sided marketplace with logistics and e-commerce.” which Rob says made them a great match.

“90% of the battle is having the right people around you.”

- William On

All work and no playbook

Getting to Series A from angel and seed stage takes a lot of work and a lot of grit, getting to Series B, even more. Fortunately, the Tidal team were able to help in the form of a go-to-market expert called Georgie Turner.

According to Rob, Georgie literally “implanted herself at Shippit for about six months” to help set up an operational manual that became their Series B Playbook. This was rich enough guidance on how to set Shippit up for success to a [future Series B raise]. Being there in person made a huge difference to the founders.

The playbook for Shippit contained all the “key metrics that needed to be landed” in order to drive the business forward. Will and Rob nod at each other, “we ran our whole business off that.” It prepared Shippit for the next capital raising round, laying the groundwork for success they enjoy now. 

When reflecting on what Tidal is like compared to other investors, Rob observes that “we've got more investment [dollars] from other partners who don't give us anywhere near as much counsel and guidance, or encouragement.” In business speak, he jokes “they definitely over-index on their investment versus their involvement.” What a compliment!

Think big and then think bigger 

A pivotal moment for Rob and Will was during a conversation with Grant, who said “you don't realise this yet, but this is a billion dollar company. You need to be thinking in terms of a billion dollar business, how you are going to change the world and what you're going to do.” It’s this kind of Tidal truth bomb that has helped Shippit to realise they are “no longer building a product, but building a company.”

Will explains that “the conversations that we're having now are around organisational design, having the right people on the bus, checking they are sitting in the right seat.” This is where Tidal has steered them, in part, toward being that billion dollar business and thinking like one too. 

When I asked if this meant they no longer felt so green, they concluded there’s always something to be green about. And despite onboarding many investors since the start, Tidal is often the go-to for advice and guidance. This can mean hands-on help or a late night phone call with Wendell or Grant to “have a glass of wine and talk about the business.”

Regardless of what you're going through, they're there for the good and the bad, thick, and thin to get you through what you need to get through.”

- Rob Hango-Zada

Foundational friends and future relationships

Rob and Will have been friends for 17 years, and in some ways it’s hard to believe they are first time founders. They are wise and self-aware. Perhaps this comes from knowing each other really well or maybe they’ve just learned to be confident and believe in their team. 

Will reveals his secret to staying calm through everything, “whatever happens you and I will figure it out and that's my secret.” Rob says their biggest strength is being able to “take outside information and apply the concepts that we've got to come up with the best answer.” Either way, they work as an inseparable team. 

When it comes to Tidal’s place in things, the founders say they “take more of a partnership based approach, which is empathy, understanding and pushing us, or encouraging us to think bigger about the problem, which is why they have been so important to us over the last couple of years.”

“Having Wendell on the board from a product perspective, Georgie on board from a finance perspective, then capital raising and how we think about our future state from Grant. All of these different people from Tidal make up a really good front for us. They’re fully part of our team.”

As Rob concludes, “regardless of what you're going through, they're there for the good and the bad, thick, and thin to get you through what you need to get through.”

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.