In this Episode
Mark Graban is the author of the Leanpub book Measures of Success: React Less, Lead Better, Improve More. In this interview, Leanpub co-founder Len Epp talks with Mark about how he has widened the scope of his work from healthcare to large organizations generally, how a bad system can lead good people to do bad things, how to view a chart as "the voice of a process," overreacting to data, his book, and at the end, they talk a little bit about his experience as a self-published author.
This interview was recorded on August 10, 2018.
This interview has been edited for conciseness and clarity.
Len: Hi, I'm Len Epp from Leanpub, and in this Leanpub Frontmatter podcast, I'll be interviewing Mark Graban.
Mark is an internationally recognized consultant, author and professional speaker, and he is is senior adviser to KaiNexus, a software company focusing on creating and fostering cultures of improvement in healthcare and other industries.
Mark is the author of a number of books, including the book Lean Hospitals, which was the first healthcare book selected as a recipient of the Shingo Research and Professional Publication Award.
His latest book on Leanpub and elsewhere is Measures of Success: React Less, Lead Better, Improve More. It's a really interesting and important book for anybody running a business that's gathering lots of performance data - which is basically any business nowadays - and who's trying to make sense of the information they're gathering, and trying to decide how to use that data, and what to do with it.
In this interview, we're going to talk about Measures of Success and how it can help organizations manage their metrics by not just reacting to noise, but responding productively to real signals.
So, thank you Mark for being on the Leanpub Frontmatter Podcast.
Mark: Thanks Len, it's a pleasure to be back again.
Len: I was going to say - I usually like to start these interviews by asking people for their origin story. However, we've actually already covered that ground in an earlier interview, which I recommend to all our listeners, and we'll link to in the transcription of this interview.
So instead of asking you about your entire background, Mark - I was just wondering if you could talk a little bit about what you've been up to so far in 2018?
Mark: We talked last time about a book that I'd published through Leanpub, a book called, Practicing Lean, that was an anthology with myself and 15 other authors. That was a really fun project, I enjoyed and appreciated the ability to do it through Leanpub, as we incrementally added more chapters to that book.
And then I stepped back - I still do a lot of work in healthcare, but I started my career in manufacturing, and I've worked with software companies and occasionally, like this year, I've done some consulting about continuous improvement outside of hospitals.
There's some common themes. At some point, big organizations are like other big organizations, and the way people manage tends to be like the way people manage in other organizations.
And so I'd had this idea to go back and just write a book of my own again. That's what led to this book, Measures of Success - trying to write something that's not "a healthcare book." The first couple that I had done through traditional publishing were very targeted toward healthcare. Here, for some professional reasons, I'm trying to reestablish in the public eye that I haven't always been a healthcare guy, and I'd like to think I have some ideas that would contribute and be helpful in other spaces as well.
Len: On that note, speaking of other spaces - when we were talking just before this interview, we were chatting about an experience you had very recently at a hotel where you entered your room and the bed wasn't made.
You were talking about how in the hotel industry, often the service workers and the people who take care of the rooms are under pressure to clean as many rooms as they can. And so they've got an incentive sometimes to try to get away with logging data basically saying they've done cleaning that they haven't done.
Mark: I wouldn't blame the individual there. They're working within a system. And when we talk about metrics and measuring performance, there's a dangerous or dysfunctional side of it, when it comes to targets or becoming a quota, where good people will get pressured into doing unfortunate things.
Wells Fargo is an example in recent years here in the US. They were running apology ads saying, "Please forgive us, we've changed," because they had a period where their CEO set this really unrealistic target - that every customer should have eight accounts. There was this nursery school rhyme to it of, "Eight is great." And I'm like, well he could've also said, "Nine is fine." Why wasn't the arbitrary target nine? So branch managers and bank tellers started opening accounts without permission. They twisted people's arms into accounts and created extra fees and all kinds of problems.
You setting an aggressive target doesn't magically lead to results.
One of the points I make in the book is, we can't just set a target. If it were only so easy, we'd just set a target. "You need to clean 12 rooms per day," or whatever the target is at a large hotel chain. You setting an aggressive target doesn't magically lead to results.
I think one lesson from lean and Toyota - it's the responsibility of leaders, as I've heard a former Toyota person say, and I love this expression: "It's the role of leaders to create a system in which people can be successful."
I don't know if that was the case at that hotel the other day. It seems like it certainly wasn't the case at Wells Fargo.
In the book, I try to draw connections between the idea of metrics. Whether it's the number of rooms cleaned per day, or the number of accounts per customer, that metric is the result of a system and work processes. And leaders, you may have a business reason to set a goal. But you also need to then work with people collaboratively to improve the system that will allow better results, and not lose that connection.
Len: This is something I think about a lot. I think about the ancient origins of treating the work being done by a collection of individuals, versus viewing what's happening as a system.
You can imagine an ancient Roman salt mine, there'd literally be a guy with a whip watching people, making sure that they're digging the salt out all the time. And in that world, then there'd be someone sitting on top of him, saying, "How much salt was dug out today? If you don't give me enough salt, I'm going to whip, you or fire you, or do something to you."
And so there's a very deep thing - the view that people have of running businesses, which is, being paranoid about people being lazy; the idea that if work isn't a form of punishment, it's not real work.
You see this manifest itself in various ways, like criticisms of Silicon Valley companies for being too cushy, or offering too many benefits to their workers, or something like that. There's a deep instinct, not just in managers, but also in workers, to think, "If it's easy, then it's not work." Or, "If it's pleasant, it's not work."
I just wanted to ask you - in your work, how do you help bring managers out of that "It's a bunch of people that I'm trying to put pressure on" view, to, "It's a system that I'm actually working with"?
Mark: That's a really interesting question. You bring to mind the common expression of, people will say things like, "Well, they call it work for a reason." Or things like that - like you said, implying that it's not supposed to be fun or be fulfilling. But people aspire to that. And there are examples of really successful companies that take a very different approach.
There's a company in my home state of Michigan, in Ann Arbor, called Menlo Innovations, that does software. And Rich Sheridan, the CEO, President of that company, wrote a really great book called, Joy Inc.. The word "joy" is very specifically part of - like one of the quality gurus, late guru's, I really admired, W. Edwards Deming, talked about how people really deserve to have pride and joy in their work. Those are two words he used.
Throughout my career, it's always been sad when people are not allowed to do quality work. When they're not allowed to have pride in their work. I saw this working at General Motors, when managers would override the front line workers who were trying to do the right thing for quality and for the customer. The manager was more concerned about the production numbers. So that was decades of dysfunction there.
It's sad in healthcare when people don't have enough time in the day to do the right work the right way. I think that's where the beauty of Lean - whether it's in manufacturing or healthcare or in the startup - is that, for one, it's customer focused. Two, there's this notion of respect for people - that it's respectful to create that environment in which people can be successful.
One of the key points in my book here is to not disrespect people by wasting their time in the course of overreacting to every up and down in a metric. I think back to our hotel housekeeper example. Let's say their goal is 12 rooms cleaned per day. Again, I'm just making up numbers. It's probably higher than that. But not every room is the same.
There are some people, I'm sure, who make a huge mess, and some people's rooms are very easy to clean. So is a room a room in terms of being a unit of work? I think a fair, reasonable, respectful system would recognize sometimes people are going to be able to clean 13, and sometimes they might only be able to clean 10. Do how do you create teamwork structures where people can shift work?
I see this in hospitals where they try to assign patients to nurses in a way that evens out the workload. But again, not every patient requires the same amount of time. So instead of micromanaging each individual's productivity number, you could probably create more of a self-managing, self-adjusting, self-healing system that allows people to work together as a team. Again, I think people generally take pride and joy in being able to work as part of a team. I think that's human nature as well.
Len: I think this is probably related to a line I found in your book, where you write, "Some of our common management practices, as taught in business schools or passed down from generation to generation, can actually interfere with improvement." Are you talking there partly about this idea of looking at a bunch of numbers and just trying to increase them or decrease them, if they're measures of bad things?
Mark: Yes. That's I think one of the dysfunctions. Because in my book I cite another great quality thinker, management thinker, Brian Joiner, who says in some of his different books that, "When management sets a target and puts pressure on people, there's three things that can happen. And two of these three things are bad. People can distort the system. They can distort the numbers, or they can actually improve the system."
So there's a time and a place for setting a challenging goal. But then you need to work with people to improve the system. If you're not doing that - you think of another example that was in the news in recent years. The VA, the Veteran's Health Administration. They set, from DC, a target that no patient should wait more than 14 days for an appointment.
That's a well-intended goal, but it was completely arbitrary. And the Office of Management and Budget- no, the Office in the Inspector General - I get my acronyms wrong - a different part of the government did an analysis and said, "That goal was unrealistic." That was the word they used, "unrealistic."
So people were under that pressure, and all throughout the country, people distorted the system by basically creating a paper waiting list that was off the books. The waiting list to get onto the real waiting list, where they would steer people towards dates far in the future that they didn't really want, or maybe wasn't good for their health. Or sometimes people just literally fudged the numbers, or there's this wonderful British-ism, "fiddling the figures." We need to be mindful of that.
In my book I try to really emphasize the connections between improvement and the metrics. That the word "results," it's right there in the word. It's the result of the systems and processes that are the work. I think there's other lessons there of connections - of not overreacting to every up and down in a metric. Because that can just end up wasting a lot of time.
I think using statistics to more definitively prove if we've improved or not - there are many times you could cherry pick any two data points from a chart, and prove improvement. But I think when you understand a few key statistical methods that aren't rocket science, you would look at a chart differently and say, "Well, looks like that metric's just fluctuating around a stable average." Instead of doing the single data point before and after type comparison that we so often see in the news or in different work places.
Len: I've got a couple of questions about that. But before I ask them, I wanted to talk about a sort of higher-level, theoretical kind of issue that your book grapples with. On the forward it's sort of mentioned by Donald Wheeler, where he talks about how there's a difference between the actual system, let's say our actual business, and the data that we're getting from it.
And so one of the mistakes that people often make is they just assume that there's kind of like a one-to-one correspondence, as you might say in philosophy, between the data and the actual underlying system. But when analyzing data, you always need to keep in mind that the data is a kind of fiction and -
Mark: Or it might be, it might be.
Len: Or it might be. But since it always "might" be, you always need to relate to it as though it is not necessarily in correspondence with reality. I guess what I'm asking about is - this is something I've encountered in my life, where if you show people the chart, they automatically assume that this is reality - even if it's a projection out into the future. What can one do to help mitigate that issue where people so easily sometimes conflate the image that they see with the underlying reality?
Mark: It's a really deep, philosophical question. That's a good question. You tell me if this answers the question, if I'm thinking about this on the same wavelength.
I think one reality is that every system will produce varying results. The question is, how much do those results vary? There's some statistical methods that are very simple arithmetic, to look at a baseline of data and say, "Okay, here's the range of expected variation for this metric." So that's a reality. Is it predictable within a range or not?
Now, one of the realities that people might hope for or assume is that when the next day or the next week's metric is put up on a chart - and that point is higher, better than the average - and higher than any data point we've seen previously... we see this in the news all the times: "This is the highest number in the last 14 years." That doesn't mean that there's a reality that the underlying system has changed at all.
This is where we need some statistical filters, as you said in your introduction, to filter out noise, so we can identify signals. Like you said, Don Wheeler - who I admire greatly, I was thrilled that he wrote the forward for the book - says managers make errors where they often assume every up and down in a metric means the underlying system is better or worse. When sometimes that underlying system, it's just fluctuating. Is that kind of to the point of what you're saying is--?
Mark: We might create a false reality based on an overreaction, good or bad in our metric. And the opposite might be true, whether it might be a change in the underlying system that we don't detect through some of our common management methods. Like if we just put a table of numbers in front of people, instead of plotting it as a chart. Humans are generally visual information processors, and we might mask the reality that the system has changed, and we should react - whether it's a positive change or a negative change - using what Wheeler calls, and I build upon this in my book, process behavior charts.
It's basically a variation of a line chart or a run chart that has some calculated boundaries around it that help us see if we have a predictable fluctuating system, or if there are identifiable signals that we've either had a short term blip or change, that we need to understand and learn from.
Or maybe we've had a sustained shift in performance, where now, because the system changed - I'll use a tangible example, from a hospital. Average waiting times might be two hours. And so we make some sort of change to the system - we have a hypothesis that says, "This will reduce waiting time." So we see the first data point says, "Okay, well now the average was an hour and 45." We can't jump to the conclusion yet that the underlying system has really truly improved.
We have three rules of thumb that we can use, and I lay these out in the book. We need to look for sustained shifts. So if we found eight data points below the old average, and now it's fluctuating around an average of an hour and a half, we would say, "Alright, we actually improved that system. It's not fake news improvements. It's not fake improvement. It's real, justifiable improvement."
There's kind of a sub-heading in my book of, are we trying to look at the data honestly, or are we fooling ourselves?" It's just trying to declare victory - those are some of the things where I'm trying to help people avoid pitfalls, and make better use of their metrics, to really understand the truth or the reality of what's happening in their organization.
Len: That makes a lot of sense.
Going back to the questions I was going to ask you. It leads me to ask - you mention that just looking at the difference between two data points, it's something that people can react to, as though it represents a real change when it might not. The question I want to ask is that, there's something that actually seems sort of counter-intuitive in your book, where you say that actually daily metrics are better than weekly metrics or monthly metrics when it comes to actual improvement. I see the point, but I guess in the context it seems a little bit contradictory to say that the difference between two data points in one blip of time, doesn't necessarily mean anything.
Len: And yet, we should look at daily metrics rather than longer period metrics.
Mark: I think the way to try to break that contradiction - I think if an organization has their old habits of overreacting, reacting inappropriately to every up and down in a monthly metric, or if you start tracking that metric weekly, you're just going to have four to five times the amount of overreaction. A weekly metric is going to tend to have more variation from point to point than the monthly metric. If we convert that to a daily metric, we don't want 30 times the overreaction. A daily metric is going to tend to fluctuate more.
This is where the rules and the guidelines of process behavior charts help us prevent that overreaction to noise. These are calculated, what we call natural process limits, above and below the average. That tells us, if this is a predictable system, the metric is going to fall between these two levels. Those limits are going to be relatively wider on a daily chart, because there's more inherent day-to-day fluctuation. We calculate those limits based on some baseline data.
There's a reason we call a chart like this "the voice of a process." It's not what we hope the process is performing. That might be our goal or our target. If we're looking for those eight consecutive data points above or below the old average, when we have a daily metric, it only takes eight days to have some of that definitive proof that we have shifted the system. If I have a monthly metric, it would take me eight months to prove a cause and effect, a significant shift in a system that's being reflected in performance.
Depending on the environment, there may be some cost to gathering data and compiling a metric more frequently. So there may be some sort of sweet spot, depending on the business.
The one trap that I see people falling into that really kind of triggered me, that motivated me to write the book is, people in healthcare generally - this might be in the practice of what they might call "Lean daily management," as that becomes more popular in healthcare - they're tracking metrics more frequently, and they're overreacting more. Or they're reacting based on rules of thumb that aren't really helpful. Like, "Well, if it's better than the target, that's green and we don't need to investigate. And if it's red, that's bad. We need to come up with an explanation." A lot of metrics tend to just fluctuate between red and green.
And so you get this dysfunctional dance of, you have a bad day - the underlying system is performing predictably, it's giving you fluctuating results, and it's fluctuating between red and green 50/50 maybe. This happens a lot when the goal is set really close to the average performance of the system.
Not every day can be better than average.
Not every day can be better than average. When people overreact to the bad day, they ask people to do root cause analysis. They say, "You need to do an A3. You need to explain that day." It's Kabuki theatre. It's the impression of responding, we're going through the motions. And people will struggle, because there is no root cause for that routine fluctuation and the metric. So, we tend to come back then a day later, or a week later or whatever the tempo of the metric is. And now it's fluctuated into the green, and people pat themselves on the back and say, "Good job," when there's just no connection between a lot of that activity and the fluctuation of the metric.
And so the point I try to make in the book is that, as the subtitle says, "If we react less, if we stopped wasting time overreacting to all of the noise in our different metrics, we can focus our effort on metrics where there's been some meaningful signal - and we can focus our efforts," and that leads to more improvement with, I think, less effort.
Len: Thanks for that answer. That was great - it really got to the heart of the sort of philosophical question I was asking before, where you say that sometimes there's no root cause. The processes we have for approaching our data can actually make us think that there are realities that don't exist.
Mark: Yes. I think one very personal, tangible example - and I wrote about this in the book a little bit - weigh yourself every morning. You're not going to weigh the exact same thing every day. And it could be based on what you ate the day before - how much you ate, how much water you've had. There's all these different factors that are all intertwined and co-mingled.
If your weight is 0.4 pounds lower than yesterday, there's no root cause for that. But now if you notice - "my weight used to fluctuate around an average of 185, and now, ooh there's been a bunch of data points, now it seems to be fluctuating around an average of 190" - now you might say, "Okay, I've gained five pounds." As opposed to saying, "Well I gained 0.4 pounds today." That's kind of a meaningless comparison if it's just a matter of noise in a metric. And that could be your own body weight.
Len: You've got a line in your book where you talk about how leaders should encourage people to collaborate, not compete. And that really crystalized for me one of the things I really like about your work, your books and your blogs and things like that, where, of course you're talking about numbers and statistics, and I think a lot of people, when they find a writer who talks about numbers and statistics, they think that probably there's some dehumanizing going on.
But in your work, it's kind of the opposite. You manage to make the numbers really important, but also not lose sight of the fact that those numbers are being generated by people. And that there's this inter-human - there's this human interaction that's underlying everything that's going on in a business that isn't run entirely by robots.
I was wondering if you could talk a little bit about what that's like when you're doing your consulting work. How do you bring managers back to the people, when you've been talking about numbers? Or is that a conflict that you don't find you need to address?
Mark: I think it depends on the starting point of the organization and some of the culture and the values of the organization. Or it depends a little bit on, how closely did they live by those stated values every day? Some organizations - every organization has really high-minded values. But whether that's the real reality or not, I guess is a different question.
I like the way you put that. It's absolutely not meant to be dehumanizing. Metrics are important in business. Deming, Einstein, others - there's variations of the phrase. Not everything that matters can be measured. I think that's maybe part of the art of management. It's a little bit out of scope. My book is not a book about choosing the right metrics.
There's an expression that I share in the book that gets used a lot: "What gets measured gets managed." I think in the two sides of that sentence, there's been a lot of books written and a lot of focus around, "What do we measure?" and a lot of arguing maybe about what the goal should be.
But to repeat that sentence - what gets measured gets managed. How do we manage? How do we manage in a way that allows people to improve their measures?
There are some other questions that are a little bit out of scope for my book that are really important. Like departmental metrics getting in the way - I can't count how many times I've heard hospital directors say, "I know I'm making a sub-optimizing decision, but that's what I'm measured on." When it comes down to budget or things - in a hospital, you look at patient flow going across multiple departments. We don't want an environment where people are being forced to do what they know isn't the right thing for the patient or the customer. And they know it's not the right thing for the business. But they feel pressured or forced into doing that. So we don't want to do that.
I don't want my book to be used to manage the wrong measures better. There is that really deep and important question for an organization - the John Doerr book, Measure What Matters, and Lean Startup and other approaches that really get to the heart of, "What should we be measuring?" Hopefully my book builds upon books like that. "Now that we've chosen our measures, let's understand how they're performing, how they're fluctuating," and trying to connect our system's performance to our goals, and understanding some of the different ways we should improve those systems.
Len: That gives me the perfect opportunity to ask you a question I was hoping I'd get a chance to ask you about. Which was, what you think about Elon Musk's latest move about Tesla?
For those listening, we're in this moment where just a couple of days ago Elon Musk tweeted out - "Look, I'm going to take Tesla private." And the reason he's doing it is because he feels that the things he's being measured on, as the CEO of a public company, are not necessarily the right things that he should be doing for the success of the company in the long term. If this isn't something that you've been following, I'm not going to ask you to just make something up, but I'm pretty sure you've probably been following it.
Mark: I started my career as a car guy. First off, I'll say I absolutely want Tesla and Elon Musk to succeed. When I've criticized some of the things they've done operationally or some of the things that have come out about their culture - and I've occasionally talked to people who work or used to work at Tesla. I'm not a Tesla insider, I'm not an expert - I criticize, because I want them to do better. I'm not a short-seller who's trying to bash the company. That's one of Elon's things. I don't own any Tesla stock.
This question of the tyranny of quarterly results. There is a real factor there. I can understand why companies would delay going public, if that's something they even want to do, because there are a lot - I think in the manufacturing space, relatively - a lot of the great lean success stories have been in smaller family-owned companies that can make long-term decisions.
Point number one out of 14 points in the Toyota Way philosophy - I'd refer people to Jeffrey Liker's book, *The Toyota Way - I'm paraphrasing it, but point one says, "Make decisions based on the long term, even at the expense of the short term." That's a really powerful part of Toyota's philosophy.
Toyota is a public company, at that same time. And it seems that Toyota is very much like Jeff Bezos and Amazon, a public company. Amazon has very famously said, "We are in this for the long term." I don't know their quarterly numbers every quarter. But I know for the longest time, they were losing money. And he says, "Look, we're investing in the growth of our business, if you don't like it, sell the stock."
I wonder if Elon could take a similar approach. Like, we're public and articulate why you're making decisions for the long term, and tell people, "If you don't like it, sell the stock." If people really don't like it, I don't know much about short-selling and finance and all of that. But maybe he needs to get off Twitter and just manage his business and let the card - the stock price is a result of the way he's managing his system, right?
Len: It's interesting you bring up Bezos there. That's I think very appropriate. He made a comment in a talk not too long ago saying - some stock analyst asked him, "Why are the numbers up? What recent decisions have you made to improve the next quarter's performance?" And he said, "Look, the next quarter's performance is based on decisions that we made two years ago." Which was very clever.
It leads me to my next question. It's specifically about - I think there's something about the car industry that's particularly driving Elon Musk's decision. Because I read a fair amount of car industry analysis from stock analysts, just as a hobby, and they have a very particular culture about like - "ramp up the numbers for the next quarter. Ramp up the numbers for the next quarter." I wonder if maybe he can't take Bezos's approach, just because of the very arbitrary nature of the type of analysis that's done in the car industry.
Mark: It's a good question, and I think some of these targets that he's being held accountable to, are arbitrary targets that he set.
Len: That's true.
Mark: "We're going to hit 5,000 a week by this date." That number 5,000 is arbitrary, the date is arbitrary. Now they could be looking at a business plan and how they expect to grow revenue. A car factory has very high fixed cost. So there's reasons to scale faster than slower.
I think part of the dynamic has been that Tesla pretty much has a monopoly on mid- to high-end electric vehicles. My dad has a Chevy Bolt plug-in electric vehicle, it has the same range as a Tesla. It's not an attractive vehicle the way a Tesla is, so it's not a competitor to that, not really. The Nissan LEAF is very small - it's an economy car size. I don't think it has the range.
But the competition's coming. Jaguar's coming to market. Audi, BMW, the others. [Tesla's] got a window where, if they don't take advantage of that and become so synonymous with electric vehicles, it's possible they're the innovator who, who loses their window.
There are different reports, and Elon Musk yells "fake news" about how many people are cancelling their orders because they're impatient, or they can't get the mythological $35,000 Model 3, because they're not really building those. They've sort of had this monopoly that they need to take advantage of sooner than later, perhaps?
Len: Moving on to the next part of the interview, I wanted to ask you about the process you used for writing this book. You used a little bit more of a "bring your own book" method for this book on Leanpub. I was wondering if you could just talk about your approach, because I know you put a lot of thought into it.
Mark: I started with Leanpub basically republishing collections of blog posts and podcast transcripts. Practising Lean was the first sort of original content in Leanpub. I wrote that using the text editor, Markdown format. There weren't many images or figures in that book. It was almost all text. So Markdown was brilliant, to be able to just generate these different formats.
With Measures of Success, my new book, I should do the exact count, but there are at least 100 different charts and figures in the book. I know I could have managed that through Markdown - technically that was possible.
Part of my process - I was definitely doing the incremental - the "publish early, publish often approach - I published first earlier this year, when it was just the first three chapters. And the promise of the rest of the book to come, classic Leanpub.
But as I was writing and I was working with an editor, and I was also getting input from people I know. Leanpub, it's great to have the opportunity, for somebody you don't know, to discover the book, and invite input and feedback from them.
Honestly, that didn't really happen more than a couple of times, where somebody would email me either because of a typo, or something was unclear. So either way, that's helpful feedback.
I basically wrote the book in Google Docs. That was great for real-time collaborative editing with the contractor that I was working with, to get input from others.
And then I was outputting from Google Docs as a PDF. So then I was uploading that PDF into Leanpub under the "bring your own book" format. Google Docs also allows you to export the EPUB format. Which I could then basically drag directly into Leanpub. I was using a piece of free software called, Calibre - I don't know how it's pronounced - to convert the EPUB to the MOBI Kindle format.
There were a couple of hoops to jump through, but again, there's the classic Leanpub functionality of adding a chapter, updating a chapter, fixing typos, and communicating updates to those early buyers. The ability to experiment with pricing. And I was fascinated. I think four of the first five people who bought the book voluntarily paid more than the suggested price.
Mark: That's interesting to see. Sometimes people drag the slider the other direction, down toward the minimum price. But that whole process is something that I very much believe in as an author. Instead of writing the book, letting it percolate for six months or nine months, or however long it takes a publisher to get it to press. And then unleashing it on the world. I love the iterative approach. I think you have to be not afraid of getting feedback.
Some of the people I invited to give feedback in that Google Doc, sometimes it was fairly pointed feedback. But it leads to a better book. You don't want to get input from people who are just going to say, "Oh, that's great."
That's the trap of any entrepreneur. They tell you in different startup classes - if you ask your friends or family about your business idea, most of them are going to tell you it's a great idea. But you want people to vote with their wallet.
So this idea of a minimum viable book, or minimum viable product - if I'd put those first three chapters out there and nobody ever clicked "buy," I would have had to do some soul searching about, "Is this even a book worth finishing?"
I think that's what makes Leanpub very much like Lean Startup approach.
That was a little bit about some of the process and some of the ins and outs of using Leanpub a little differently this time.
Len: Thanks very much for that really great description. I'm really interested in what you said about using Google Docs - not only to produce the book files that you needed, but actually as a way of getting feedback. Because although we've got forums and Leanpub authors have always used the "Email the Author" feature and things like that, or just handing out their email addresses - being able to use Google Docs to coordinate feedback and still use Leanpub, is something that is really interesting.
Well, thanks a lot Mark, for taking the time to do this. I really appreciate it. It was really fun, and thanks for answering the questions just about my personal interests, which I really appreciated, given your expertise in these areas.
Len: So thanks very much. Congratulations on completing the book, and best wishes for it's success.
Mark: Thanks Len, thanks to everybody at Leanpub, I appreciate it.