How to launch your book like a startup (lessons learned)

I’ve recently had a number of conversations with people about writing books. Mostly we’ve focused on process. What are the most effective approaches? What have you learned from experience? What have you learned from others? What would you do differently next time?

The common theme across all of these conversations is uncertainty. Namely the uncertainty of a write it > release it > see what happens approach.

Although there are examples of writing approaches that more closely represent how we design and develop products and services in our daily roles, these approaches are exceptions, not the rule.

I’ve been writing for quite some time. In fact, some of my content has been fairly popular (at least for someone with a limited following).

But until last year the closest I got to an experimental writing approach was seeking feedback prior to publishing.

So, when Data Transparency Lab (DTL) and >X set out to develop content that was practical, actionable and above all, valuable, I knew I needed to change tact. I needed to start treating content differently. I needed to start treating content like the products and services I’ve contributed to throughout my career.

Changing tact enabled us to publish Designing for Trust: The Data Transparency Playbook.

The playbook has been well received.

“Years ago I urged people to embed Privacy, by Design. With trust at an all-time low, it’s now time to design for trust. And the best way to overcome the data-trust gap is with Data Trust by Design. This is an essential ingredient to enabling user empowerment. Use this great playbook to make trust your competitive advantage!”

— Ann Cavoukian, Ph.D., LL.D. (Hon.), M.S.M. Privacy by Design Centre of Excellence, Ryerson University and Inventor, Privacy by Design

It’s also been put to pretty good use.

This post isn’t about the book we developed. It’s really about the process we engaged in to take the book from an idea to a product. To do this we’ll guide you through the series of steps we executed. Although the steps seem linear, it’s important to note each had multiple feedback cycles.

In this post I’ll:

1. Break down the process we executed
2. Share practical insights I trust will help you with your next writing endeavour
3. Detail where we went wrong and what we learned, and

You should read this post if:

1. You’re looking to increase the consistency of your writing output
2. You’re looking to enhance the impact of your writing
3. You’re considering publishing (regardless of method) a book

Let’s go.

Step 1: Defining an outcome

If you were to ask me why >X exists, the commercial chap in me would say something like, “We exist to help brands evolve their culture, workflows and practices in such a way they’re able to systematically release inherently trustworthy, data-driven products and services to their customers.”

But really the simple answer is that we want to contribute to a high-trust digital economy. We hate that the status quo today is mistrust.

Although we’re small, we’ve got some tools and approaches that enable us to do this pretty effectively in certain contexts. The challenge, given our current business model, is scaling the impact of our work. Scaling means enabling people to design for trust without our direct assistance.

Thankfully we were pretty aligned with the DTL from the outset. This made defining the outcome we were working towards pretty easy. We wanted to give people a simple, actionable toolkit that could help them bring trustworthy products and services to life for their customers. Again, we needed to eliminate any direct reliance on our services.

With this shared clarity we kept moving forward.

Step 2: Define constraints

We’re all familiar with constraints. Sometimes we love them, sometimes we hate them.

In this case, our constraints were pretty simple;

1. We had a time constraint
2. We had a budget constraint (big surprise!)
3. We had people constraints (i.e. only Bianca and I were working on this directly)
4. We had technology constraints

Basically this gave us a way to start assessing what was and wasn’t possible. In fact, it helped make this super clear. We knew at this point a static publication, delivered through our website and marketed through our network was the way to go.

We didn’t feel great about it. We wanted to be more ambitious. But we had to work with the constraints. We had to get creative!

Step 3: Framing a point of view

The way I see it (please excuse the oversimplified view) is there are two core approaches to product development. The first is hypothesis driven. This is often the approach employed by startups. It’s why Customer Development is so useful.

The second is discovery driven. This is often the research driven approach employed within larger organisations.

I’m not here to say either is right or wrong. I won’t even dive into which is more effective. It depends on context. What I can tell you is that we kicked off our effort with the former. We started with a hypothesis based on a key insight we’d discovered and validated in our previous work. Weirdly you could then say it was research driven, but let’s stick to my assertion for simplicity’s sake.

This insight was that data transparency has the single most significant impact on a brands perceived trustworthiness. It’s important we are really clear on the ‘perceived trustworthiness’ part of this equation. Just because a brand is transparent about their data practices doesn’t mean they are trustworthy. Trustworthiness extends far beyond data transparency alone.

The reason we liked this is because we’d had the opportunity to put this to the test in previous projects. We also felt it was simple and actionable. We were confident we could take this insight and turn it into something useful.

Our hypothesis was basically… “by giving people a simple toolkit with clearly defined practices, we could help individuals, teams and organisations deliver increased data transparency to their customers with minimal workflow disruption.”

You’ll note the independent variable (the cause) is the toolkit (and the practices). This is the thing we can control. The main dependent variable (the effect) is increased data transparency. This is the thing we want to achieve and of course, observe.

Interestingly we added an additional consideration. We wanted to try and find a way to do this with minimal workflow disruption. We called this out explicitly because we wanted to be realistic about the impact of this project. Given our constraints, there was only so much we believed we could achieve.

Step 4: Define riskiest assumptions

The riskiest assumptions of every project will differ. However, there are almost always common themes. Here were ours;

1. The topic won’t resonate
2. The practices won’t work
3. No one will find it
4. No one will buy it
5. No one will read it
6. No one will take action

Although there were other considerations, these were the uncertainties we had to directly tackle if we were to achieve the outcome we were motivated by.

*You’ll note the above is inverse. The actual assumption is, “the topic WILL resonate” etc. We wrote the 6 points above in their negative form because it felt easier for us to understand.

Step 5: Write > Measure > Learn (Repeat!)

We managed to work through the early stages (steps 1–4 as above) very quickly. We needed to given our constraints. This meant we could kick off our design process quickly.

This, although short in relative terms, was the longest part of our process. It required us to execute a series of activities; some of which we could do from our apartment in Rome, for others we needed to get out of the building (both physically and digitally).

Diverge, converge

Bianca and I got started; constraints and riskiest assumptions defined and visible.

We started with some collaborative exercises on paper. We took our constraints and extrapolated. We diverged upon a wide array of possibilities, ranging from how we delivered the experience through to how we might get people’s attention. We then converged.

From this we framed a clearer point of view about the product we were designing. It was a playbook, not an eBook we thought. It was something that people could take to work and make use of on a regular basis. It needed to be engaging enough for people to stick with it. It needed to be practical enough for people to do something more that just read. It was like a hands on workshop or program, delivered via a PDF!

Can’t believe we said that with such excitement. Stick with me.

We also figured we needed to help readers achieve three things if they were to make real use of the content;

1. We need to help them get the gist of what was actually going on in the market; what were the regulatory, technological and behavioural trends
2. We needed to help them understand that it was actually about customer innovation, not data activity, and
3. We then needed to give them a practical toolkit to design transparent experiences — without disrupting the way they work today.

We then took this perspective and did what we could to assess it objectively against our experiences, the tools we had already developed and the challenges we’d already faced helping organisations do this stuff internally.

It seemed okay at the time, so we drove forward by seeking feedback on the point of view we developed. We did this simply by reaching out to a bunch of people within our network to learn about the current challenges they faced. We learned quickly that they might buy into our perspective, and better yet, if we gave them something of real value, they may advocate it to their colleagues. Attitudinally (always back up your qual with quant!) they expressed interest in our product.

Onto the next.

Developing the plays

Based on the work we’d done and the things we’d learned we felt there was an opportunity to break the publication into three distinct sections. One of the ideas we’d come up with was gamification. We had a plethora of cool ideas, but most of them just weren’t viable or feasible. Remember, we needed to execute a (fairly) static publication.

We sought inspiration. We looked at things like Octalysis. We looked at the 4 keys to fun. Eventually we came back to something that was relatable to us — something we later defined to be relatable to others too — sports.

We decided to break the content down into plays. It was almost as if we were the coach and the reader was a key player on the team. We wanted to guide them through the plays, give them feedback on their performance and help them progress towards their goal.

Before putting this concept to the test we had to pull together some key content.

Writing

Fortunately our writing effort was quick. We’d lived this stuff for long enough we could draw on previous work and tools we’d already developed to bring the core content of the playbook to life. In all it took four three hour blocks to write the first version of the content.

This was by far the easiest part of the process. In hindsight we think this was easier than expected because we’d put in work prior. We’d framed a clear point of view. We knew what we wanted to achieve. We had the practical experience to support what we were writing.

Put it to the test

We then had a couple of very distinct challenges to tackle. The first related to the content; its relatability, its comprehensibility and its relevance. The second related to the plays; primarily their efficacy.

We wanted to put both of these things to the test as quickly and effectively as we could.

We decided to separate these out and run them in parallel.

To test the content we did two things;

1. Release snippets of content (basically sub chapters) via the InVision Blog, and
2. Send the content to key people in our network we trusted (who were kind enough to invest their time in helping us!) and who knew the domain like the back of their hand.

This enabled us to ‘get out of the building’ so to speak. It helped us have conversations with a broader audience. It helped us learn about what resonated and why.

To test the efficacy of the plays we had to get our recruiting hats on. We needed people to read the content of the plays, put them to the test and report back on what was and wasn’t working. We had to contextually inquire so we could dive deeper into why the plays were or weren’t working.

We tackled this progressively. First off we did this with individual plays. We refined. We then tested the three plays together. We refined again.

This process, although a little messier than we would have liked, challenged us in ways we weren’t expecting. It helped us simplify the plays. It helped us refine the language. It helped us become more prescriptive. The result of this was a greater feeling of confidence that we were really moving in the right direction.

Then there was a bonus.

We were in the process of running a workshop series throughout Europe with the DTL. This gave us the ability to test the plays, particularly Play 3: Evolving your design practice, with workshop attendees.

Not saying everyone has the opportunity to conduct workshops on the exact contents of the publication they’re developing, but if you do, it’s highly recommended. This was perhaps the most meaningful activity we engaged in throughout our write > measure > learn process.

Bringing it all together

After releasing multiple iterations of our product (i.e. MVP’s) we felt we had enough qualitative and quantitative insight to bring together the final version. Like I mentioned above, this process increased our confidence. It perhaps also increased the likelihood we were going to release a valuable, meaningful and engaging product to market. But it certainly gave us no guarantees. In fact, a heap of work remained.

Because we were self publishing, we needed to figure out how we’d distribute the playbook, how we’d price the playbook and how we’d support readers who wanted to progress beyond the contents of the playbook.

Although we’d worked through this progressively, and effectively defined a distribution strategy early on, executing was a different story.

Step 6: Release management

This was where it got real. We had to finalise everything from a payment services provider (so we could sell the playbook) through to strategic partners that could help us get our product to people who may genuinely value from it. We didn’t allocate budget for paid activities, so we needed to get pretty creative.

We managed to organise a few things that were really valuable, like speaking engagements, partner blog posts and direct distribution relationships with large organisations. They helped us massively increase distribution.

But it wasn’t all fine and dandy. A heap of people didn’t deliver on promises. Everything from simple things through to stuff that really felt like a game changer. We pushed and we pushed, yet certain things didn’t go our way.

Much of this could have been avoided. We know for next time :)

Step 7: It ain’t over when you’re ‘done’

By the time you publish, whether with the support of a renowned publisher or off your own back, you might feel like the battle has come to a close. You may even feel like you’ve won.

The reality, at least from my perspective, is that this is when the hard work really starts. This is when you have to find ways to get the thing you’ve created to the people who might value from it the most.

You yourself have to be your biggest advocate, which for a lot of us is a really uncomfortable thing to do. But if you don’t believe in it, what’s the point?

I’ve become more and more comfortable with this over time. Although I’m not quite Glengarry Ross, I recognise the reality that we spend our days selling, whether we think of it that way or not.

What matters most is that you’re selling something you believe in.

So where do we get to?

What I learned

The process of designing and supporting the distribution of this publication was incredible. For me it was a first. Although I felt like we approached the effort fairly strategically, I learned a heap along the way. I made a heap of mistakes in the process. I feel better prepared for the next time I give this a crack.

Here are my three key takeaways;

1. Content is a product. Treating what we write as a product will help us execute a process that increases the likelihood our content is useful and usable
2. Don’t ever go it alone. You’d probably be surprised how willing people are to help you — I mean really help you — if you just ask them. This means research participants, partners, distributors etc. The more the merrier!
3. Think about the switch (if you don’t know what I mean, read the book!). You’ve got to consciously design an adoption pathway for people. You’ve got the help people change their behaviour. This ain’t easy, so do what you do best; frame a hypothesis, put it to the test and refine based on what you learn. This is something we learned in hindsight. We didn’t think about it anywhere near enough throughout the process. Next time we will :)

Although I reckon I learned a heap more, these are the three things that matter most to me in hindsight. They’re also the three things I’m thinking most about as I approach my next publishing effort.

If you’re still here, thank you for reading. I really hope you got something out of this.

If you’ve had a similar experience, please reference it in the comments below. I’m seriously keen to keep learning from others who are out their sharing their ideas with the world.

Until next time.