Hello,

We spent February counting down to onboarding our first customer, as well as having conversations with labs who want to try us out. It’s been a month of making sure that Sundog will land exactly as we want it to, in both the processes we set up and the stories we tell.

If you’re interested in the shortest version of our story, you can see our brand new video trailer here - and read on for more detail on what we’ve been doing.

Alex Mitchell | CEO Update

We’ve hit a point where several labs want to try Sundog out. This is, obviously, great. It tells us that we’re solving a real problem - one that people will pay money to solve - and that the story we’re telling about our solution resonates with our target market. We want a lab piloting Sundog to see, as vividly as possible, that this is something they can’t live without.

Pilots are going to be an important part of how we sell. Every lab has a different workflow and culture. People need to use Sundog to know that they can make it their own - biologists always want to know that things will work in their hands.

In a pilot, a lab gets a month of access to Sundog, and a small amount of storage. There’s no automated signup for that right now via our website, because setting a lab up isn’t just about adding some entries to a database. We also need to understand how our individual customers needs and work.

The first thing that we want to learn from a potential customer is that they have a problem we can solve. That starts by checking we can work with their data. Data from microscopes is really heterogeneous; it can come in the form of 2D files, 3D “z-stacks”, time series data, arrays, or any combination of those. We get a prospective lab to send us a sample of the data they would want to work with, which we can load up in Sundog for them - to confirm not only that we can read it, but we can work with it in a way that they are happy with..

We also spend time understanding how they want to work in Sundog. People will work with their labmates differently from the way they work with a collaborator in another timezone; the more we know about how their teams and processes, the better placed we are to support them.

Once we’ve both agreed to kick off the pilot proper, we can onboard them properly. To return to Tom’s discussion last month on the complexity of making tools for professionals - designing for learnability sometimes means that we add the most value by taking a teaching role: walking them through the product with a focus on their specific use-case.

We also set up our support processes for them. The trial process includes regular meetings to discuss feedback and feature ideas - so our time together will be valuable for both of us.

All of this is to say, we treat our pilot customers with care. Sometimes, that includes saying “no” to problems we’re not ready for yet. There are still enough biologists who struggle to share and collaborate on the sort of data with which Sundog works brilliantly. These are the people for whom a pilot will succeed. They’re also the people who will spread the word about our product, both by talking about Sundog and inviting their collaborators to work with them there. Pilots give us the best opportunity to meet their needs, and set them up to be enthusiastic supporters from day one.

Tom Armitage | CTO Update

The technical work of the past month has been some some long-running, large changes, that have taken time to build, review, and land. I want to get these big features completed before we open up to customers, so we don’t have to introduce them to a major product change only a few weeks after launch. That’s a bad experience for them, and it’s a hard story for us to tell.

I’ve been thinking about telling stories a lot this month. Launching a new product means telling its story a lot; often repeatedly, often to the same groups of people, to remind me what it is.

How can we make telling that story easier? How can we build storytelling into our processes and tools?

Obviously content is part of that. This month, we released the new video trailer of the Sundog product. We’ve had neat demos of features - detailed walkthrough of a product area - in the past few months, but the last end-to-end demo we had was a walkthrough of the original prototype (known to us as “Scafell”). That was a baggy eight minutes or so, but it was the last time we had anything audio-visual explaining the Sundog product vision. And it’s changed a lot since then!

So the work to get it down into a couple of minutes was really valuable. We now have a shareable artefact that doesn’t just show off the real working product: it also tells a story, about what the product is and what it enables scientists to do.

Videos like this are high-effort: they need recording and editing. But there’s a time and a place for lighter-effort clips, either alone, or in the context of text, just pushed out. For a very visual product, video explains it well, and I imagine I’ll continue to be firing up Screen Studio regularly in the months to come.

There’s also textual content on the site. Right now, the website is a simple splash-site to explain what we do and how to reach us. In time, it’s going to have to service the need of communicating both case studies of users, and updates to the product. I like the work and thinking Buttondown have recently done about this - here they are talking about how the way a company communicates change needs to evolve over time.

But storytelling isn’t just the remit of marketing and content.

We’re planning the product onboarding sessions for customers right now. It’s important people leave them set up with the product and happy to start using it - but it’s as is important they leave with a mental model of what it is, how it works, and what it’s for. That’s also a narrative: so making sure our onboarding tells the product story well is really important.

Documentation, similarly, is a great place to reinforce this. We have user-documentation inside the product right now; a comprehensive user-guide for how to “drive’ the product. It looks like this:

Documentation tells a more detailed story about the product. If it was on the public-facing site, a prospective user - perhaps with more technical inclinations, like core facility staff - could glean more about the product via it. I know that I usually read the documentation for any technical product before I consider buying or signing up. And that means the documentation isn’t just a user’s manual: it’s also another space to tell the Sundog story.

That means the value of making the documentation not only good, but also up-to-date, is high, and it's worth investing in processes to make that easier. I've currently got a back-burner project to automate all the documentation screengrabs, ensuring that they're not out-of-date with the rapid change of the product, and making doing the right thing easy.

Finally, there’s the stories we tell ourselves at Sundog. Recently, the product roadmap has bifurcated a little. The “next up” pile is now just everything we need to do to get to launch, and is shrinking daily. But the “backlog” is piling up, and, as we navigate the first few weeks of teams using the product, we also have an opportunity to refocus and work out what the next stories we want to tell with the product are, and how we can make them happen. We start by telling them to each other - and that means getting the team together in person a bit over the course of March.

We’ve spent the month preparing for the next stage of our life as a company. Thank you for your support as we do that - and if you want to talk more about what we’re building and how, just reply to this newsletter or email alexandra@sundog.bio.