In this Episode
Paul Redmond is the author of the Leanpub book Docker for PHP Developers: A guide to using Docker for PHP development. In this interview, Leanpub co-founder Len Epp talks with Paul about his background, his work for Laravel News and his Bitpress project, his process for writing books, what it's like having a self-published book picked up by a conventional publisher, 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 28, 2018.
This interview has been edited for conciseness and clarity. Conversational quotations of third parties should be treated as paraphrases and not be used for attribution.
Len: Hi, I'm Len Epp from Leanpub, and in this Leanpub Frontmatter podcast, I'll be interviewing Paul Redmond.
Paul's a full stack developer and author based in Scottsdale, Arizona. His books include the Lumen Programming Guide published with Apress, and the Leanpub book Docker for PHP Developers: A guide to using Docker for PHP development.
In this interview, we're going to talk about Paul's background and career, professional interests, his book, and at the end we'll talk about his experience using Leanpub a little bit.
So, thank you Paul for being on the Leanpub Frontmatter Podcast.
Paul: Thanks Len, I really appreciate it. It's nice to be on here. I've got my Laravel News shirt on. You guys can't see that, but I'm sporting it anyway.
Len: I saw that right away, that's great.
I usually like to start these interviews by asking people for their origin story, so I was wondering if you could talk a little bit about where you grew up and how you ended up being involved in software development?
Paul: I'm a bit like my grandpa, I'm a homebody. I was born here in Phoenix, Arizona, and I've lived here my whole life. My wife's always trying to get us to travel and move, but I guess that I'm a homebody, so I've been here my whole life, for about 38 years. I spent a little time in Columbus, Ohio on a church mission, and really grew up here in the heat, and eventually learned about programming after I was married. I was about 22 at that time.
Len: Most of the authors I interview who are programmers and went to university, studied computer science there. But I believe you studied business at university, if I read your LinkedIn profile correctly?
Paul: Yes. So I'll try to make it short, because it is a little boring, I think. But I started as a mechanical engineer, and I was doing an actual apprenticeship with a mechanical engineer that was kind of a - I would say an old school mechanical engineer. He served in World War II. And besides learning how to do some old school machining work, he taught me a lot about respect and honor and taught me some really good old-fashioned skills, I would say.
So I got that experience, it was nice. But it also taught me that that's not really what I was interested in doing with my career. So it was good that I just went for it and tried something, and then later found that it really wasn't something I was interested in doing.
Len: You referenced your mission, and actually that's something I wanted to ask you about. On your Twitter profile you mention that you're Mormon, and you mention your mission on LinkedIn. Actually, I've had the opportunity to ask a couple of people on this podcast in the past about their missions, and I was wondering if you'd like to speak a little bit about yours? You mentioned you went to Columbus, Ohio.
Paul: Yes. I went to Columbus, Ohio - so stateside. We have missionaries all over. But like I said, I mostly grew up in Arizona. We didn't travel a ton, so I hadn't even really been out east very far. So it was my first time away from home. I was 19 years old, it was a huge learning experience. It really puts you into an uncomfortable position. You have to open your mouth - I'm very introverted, and I think that's partly why I love programming and web development.
But it makes you get outside of your comfort zone. I just learned a lot of those soft skills that I believe you need to be successful these days, so it was really helpful.
I think just making it two years on your own at that age, and doing something that you're not forced to do, was a big accomplishment. It's volunteer. There is some pressure from within, I would say, religious pressure to go on a mission. But in fact I actually wanted to go.
...in a knowledge worker career, you're always going to face these challenges, where you just want to quit, and you just keep going.
Anyway, I think that it really helped shape a little bit of my character, and helped me endure some things that maybe were challenging. I think some people can relate to that - in a knowledge worker career, you're always going to face these challenges, where you just want to quit, and you just keep going.
Like I said, I learnt a lot of soft skills by doing my mission.
Len: And did you have a partner with you?
Paul: Yes, so we always go in pairs everywhere. And so you get to meet different people, and you actually learn some of your likes and dislikes. I'm sure the college experience is probably similar, if you have never had roommates. So getting that experience of learning your likes and dislikes and roommates and other people, was really fun, and I have a lot of good memories and friends that I made that I still keep in contact with from it.
Len: It's interesting you talk about how it's volunteer, but at the same time, what you volunteer for kind of forces you to talk to people and things like that.
I've been interviewing people who are software developers for years on this podcast. I mean, if they're on Leanpub, they've already come out of whatever shell they were in, to some extent. But often one of the stories that people tell is that, in order to be a successful software developer, you actually really ought to do things like go to conferences and try and give talks and things like that, because it'll help you network, it'll help you find your next job, it'll help you learn. And it's a very, it's a very welcoming community. And Laravel in particular, I believe has a very welcoming community.
Paul: I was just at Laracon, and it is my [first?] tech conference. I've been a software engineer for 15 years, I just have never taken that step. But I would also say the local meetups, I've only been to a couple, but that's another really good way to come out of your shell a little bit, and it's a smaller stage as well, to see some interesting presentations, and then talk with people afterwards, and just kind of come out of your comfort zone and network with other people.
I had a great time at Laracon. It was just a lot of fun.
Len: One of the really fun things for me about this podcast, is that I get to interview people from all over the world. And often they have - for example, you might hear something about Spanish independence movements in the news or something like that, and if I'm interviewing someone in Spain, then I can ask them, "What do you know about this as a local?"
I wasn't planning to ask you about this initially, but just recently, I saw on the news that it was announced that members of the Church of Jesus Christ of Latter Day Saints are no longer supposed to refer to themselves as Mormons or even use the acronym LDS. I'm really curious how you've seen the response to that, or at least if you can maybe talk about your own experience? I mean, there's a lot of Twitter profile updating to do, if that's really happening.
Paul: Yeah, that's an interesting thing. I mean I'm obviously not speaking officially for the church, but I hear both. And our external facing website, I believe one of your last guests - because I listened to your podcast as well - had mentioned that he worked on the morman.org property. And that's definitely the way that people identify us. And so I mean, - it's a familiar term. The actual name of the church is, "Church of Jesus Christ of Latter-Day Saints." But I feel like it's not important to correct people if they refer to you as a Mormon.
In the old days, the history of the church - that was like a derogatory term. But it's actually, I would say, lost that meaning, and it's just a term. It's because of the Book of Mormon, and - anyway, I think the best approach, and this is true of many other things, is just to not correct people. And if that's how they identify your church, and they ask questions, I think that's more important than correcting them.
Len: That sounds like a very wise and considerate response.
Paul: Thank you.
Len: And very polite and nice as well. I would say from my own personal experience, I don't think that people nowadays - when they hear that word, associate it with any particular kind of negativity.
Paul: There's obviously - we have beliefs, and there are certain stances that I'm sure that you've heard of that - and we are in the more conservative realm of politics, I would say, just generally. But the thing that I take away from the church the most, is the goal and the mission is to love people and to help people. And that's in my opinion, the most important thing as you outreach to other people. The church is very involved in helping communities inside and outside of the United States, that are impoverished, that need help.
We have a perpetual education fund where members are encouraged to donate. And it helps people in third world countries and other countries that wouldn't be able to get an education to fund that.
The other cool part that I personally like about that, is once that person goes through that class, they can help and invest back into the perpetual education fund as well. Hence the word, "perpetual," which I think - Anyway, I think what I'm trying to say is that, in my opinion, the most important thing about my religion is trying to be tolerant of people and respecting everybody, and just showing love and kindness, regardless of differences.
Len: Speaking of education, that's a good opportunity for me to segue into your own work in that area on bitpress.io.
Paul: Jacob and I have worked together professionally, and actually there is another book that was originally on Leanpub. It was my first book that I wrote, called Lumen Programming Guide, it's now published by Apress. But Writing APIs With Lumen was the original book, and I started it on Leanpub. Someone contacted me from Apress to publish it as a book. So that's kind of my origin story, I guess, as a publisher.
I was so inspired by the writing process that I wanted to continue that and Bitpress is like my home. It's very unpolished, I'm still working on it in my spare time, I have a full-time job. But the idea is that I want that to be a place where I create courses and content and even software, to help developers learn and grow as developers.
Len: And when did you start working for Laravel News?
...writing a book presents other things besides money.
Paul: I started that about a little over a year ago. It was definitely a cool way to start - Eric just contacted me, because he noticed that I had written a book or two, and was interested in finding somebody to help him write content for the site. So he just reached out to me. I think what's really important for this podcast is that writing a book presents other things besides money.
Also, it opens doors and opportunities. Maybe that's part of why he reached out to me in the first place.
But ever since then, I've gotten to know Eric, and we have a really good relationship. And I've - I just hit over 200 articles on Laravel News, so yeah, so it's a lot of fun.
Sometimes I'm a little worried that I'm going to dry up and run out of content. But we try to feature community open source projects. So that helps as well, as I try to write a few tutorials here and there.
Len: Thanks for that great answer. I should say - when you say "Eric," you mean Eric Barnes.
Len: ...who heads up Laravel News. How many people are on the team?
Paul: It's Eric and me. Eric Barnes founded Laravel News, and he was writing the content all by himself - and has grown it to what it is today, and has written thousands of articles. I'm pretty sure his count's pretty high. I think he wanted some help on the writing side, just to allow him to do other things with the business as well.
Len: And how do you guys decide what to write next?
Paul: He gives me a lot of autonomy. Sometimes he'll bounce ideas off of me, or I'll bounce ideas off of him. We just have our own internal Basecamp board. Some weeks, I don't even tell him what I'm publishing. I just create some to-dos for it. He'll obviously receive notifications, but yeah, it's very autonomous, and he does put a lot of trust in me to publish stuff that people will be interested in.
Len: And what is the latest Laravel News?
Paul: Well, Nova is the latest Laravel News. I guess this week will be Laracon EU as well. But Nova just came out, and that was the big reveal at Laracon US. Now it's available, too.
Nova is a administration panel for Laravel that allows you to make really cool custom administration panels with your existing code base, your Laravel code bases.
Len: I had the opportunity to interview Taylor Otwell, the founder of Laravel, just a few days ago for the second time. Five years had elapsed, and I actually didn't know this, but he had just announced Nova. So I watched his presentation on YouTube, and it was fascinating to see the product of all that work.
Paul: It's really awesome. I was really impressed because I've been on teams where we've had a couple of developers full-time building administration panels. It's really impressive, what he and David Hemphill - who helps him - cooked up, it's really cool, it's awesome. There's a lot of community involvement going on as well right now. A lot of people are building Nova packages now that they're open sourcing and sharing with the community. It's pretty cool.
Len: It's interesting what you mentioned about how publishing a book is about more than making money. Just yesterday, also inspired by the upcoming Laracon EU - I interviewed Jason Gilmore. He actually has a past working in technical book publishing, and he's written hundreds of articles himself. I don't know how much of that he does these days anymore. But he talked about that as well, and that actually leads me into my next question.
Which is: if you're going to be an author, then you have to figure out how to write a book. And you have a really good blog post, that you wrote a little while ago now, about your writing process for your latest book, where you really break it down. It was really clear and methodical, and I personally have to say I really appreciated the emphasis on outlining - which is something that I like to do for most of my writing projects.
I was just wondering if you could talk a little bit about, what's your process from when you first sit down to start planning, to when you hit the publish button, whenever that happens to be?
Paul: Thank you, I do appreciate that. In fact, I was hoping to create more, either video or written, content about this very topic as well. So it is interesting to me.
Out of all of this, I think the number one key for me at least - and this might differ for other people - I have to start in the middle somewhere and just get going. I'm doing a screencast series right now, on Docker as well. I've released my book, but I'm also doing some videos.
And I have started in the middle. I don't know why, but for me, I go right to the exciting stuff, and I skip the intro -type stuff. Because I want some momentum, and I feel like that more interesting, engaging stuff really helps kind of set that tone for the book, or any other piece that you're writing. Even when I write articles sometimes, I'll just start in the meat of the article, and put a title for the intro and just leave it blank. Because a lot of times I refine it anyway at the end. Maybe that just works for me, I don't know? I haven't really proven if this is something that helps other people. But yeah, I just get started.
The other thing I do is, I create all of the chapters in Leanpub. In my Book.txt file, I have every chapter that I've planned.
And actually, there's a step before that - creating the outline. What I like to do is a like web diagram, or any other way to brainstorm different topics. And then, I start to see patterns, and then I extract those and create a chapter outline.
The other consideration that you have to take is, this person is learning something where they might not have any idea about the topic. How can I organize this in a way to incrementally teach them something?
If you're introducing a concept in chapter two, does chapter one cover any basics behind that concept so that they understand it, or building up to that concept? Those are all important considerations for me.
The other important thing, at least for me, is getting feedback early and often. When I set up a Leanpub project, I'll push to GitHub, and Leanpub - maybe you guys love me for this, but every time I push to Leanpub, it generates a new version of the PDF. I like to review that often. For me, it's just some kind of satisfaction of seeing it in a PDF form.
I guess I'm kind of all over the place on this. But in a rough sense, that s the way that I approach the writing part of things.
I also use Grammarly heavily. And I would recommend getting an editor. But in my case, it just wasn't in the budget. And so I used Grammarly and ran it by a couple of my friends as well.
Len: And how do you use Grammarly?
Paul: What I do is, I do a lot of the manuscript writing first. I'm not even touching Grammarly until the book has pretty much a full form.
The other thing, that I would say is contrary to the way Leanpub does things, is I kind of keep things hidden. It's my personality. I'm afraid to show work-in-progress code to my co-workers sometimes. I'm kind of an OCD perfectionist in that way.
So a lot of times I'm doing my work in the background. I know that I need to come out of my shell in the future, in that regard. But the book has a very nice shape before I'm ever getting into Grammarly. I do it chapter by chapter, is how I go about it.
Len: I was going to ask - you actually wrote in your post that you "like to write in secret and release all at once." We are very accommodating of all approaches to writing at Leanpub, but that's obviously not our advertised advice. But you just mentioned that you actually like to get feedback early on, unless I misheard you.
Paul: Qhat I mean is like, my own internal feedback.
Paul: My own feedback loop. I wrote it - it looks like a Markdown document. But it doesn't really have like a design form, like a PDF format. So I guess that's what I mean, is I'm constantly pushing up changes to Leanpub in order to generate a new version of the PDF.
Len: And how do you create that custom-designed PDF?
Paul: On this project I decided to kind of take it up a little notch. Last time I launched with the generated content from Leanpub, and I just wanted to control the design a little more. I know that you guys are friendly to this anyway, like you can export the book - I believe as an InDesign artefact, is that correct?
Paul: So I went with this open source tool that I noticed, called Scribus. It's kind of like an open source version of InDesign - but it's open source, it's not as polished as the Adobe InDesign product. And there are a few features lacking.
I basically designed [the PDF], and again, the one thing I guess I learned from this process, is that the mistakes and changes in grammar are very expensive. Because you're basically typesetting a book.
At least maybe, I'm just a rookie at this, I don't know? But when you drop in the code examples, and let's say that there's a bug in the code and you have to add a couple of lines to the code example - it may push down the content onto the next page. And now you have to shuffle every page after that in the chapter. It's very painful. I'm looking at ways to improve that process, because I like being able to customize. And even if I wanted to add an illustration, somewhere custom in the middle, it just gives you a lot of flexibility, and I thought I'd experiment with it.
Len: That's actually a really interesting feature of so many Leanpub books, that they are about programming. And if you're writing a programming book, you have all the challenges of a person writing a normal book. But you also need to write code that works and keeps working. So there's an extra kind of "grammar" that you need to stick to.
You mentioned in your blog post that you use a test-driven development approach to your writing. Is that what you were talking about?
Paul: Yes, that's what I was going to mention. So with my current book, Docker for PHP Developers: A guide to using Docker for PHP development, there's not as much opportunity for test-driven development, as there would bein a coding book like with a programming language.
But in my first book, in the Lumen book, I actually wrote that the style of the publication is test driven. So every concept in the book, you write a test first. And then you write the actual code to make the test pass.
A side effect of this is that I did not have very much errata. So either a), not a lot of people read my book and reported it, or b), that the code was really well tested, and there was no errata. I don't know the answer to that, honestly.
It was my first book and I felt like I botched the communication, marketing side of it a little bit. I didn't really get a pulse of the readers. I get people reaching out to me and telling me that they really liked the book, and learned a lot from it, and shared those things.
In the end, I was very confident of the code in the book, because I wrote tests for it. So even if you're not presenting the actual tests as part of the book - if you have those in the background, it's going to make your content much more robust and you're going to have more confidence in your code samples.
Len: You mentioned your Lumen programming guide and the story about that book. I wanted to ask you about that.
One of the really good outcomes that we look for from Leanpub books is actually that they get picked up by publishers and then retired on Leanpub. It's something that we really get excited about. That's one of the things we want to be there for. And so, I just wanted to ask you a little bit about how that happened. I mean, did you get an email saying, "Hey, we found your book and we'd like to publish it. Are you up for a negotiation?"
Paul: I believe somebody at Apress purchased the book, and probably checked it out. And then they reached out to me via the Leanpub contact form, I believe. So I think it is cool, that publishers are scouring Leanpub, looking for books that might fit their publisher or whatever. They reached out to me and - again, I was like, "Hey let's try this out."
I've never published a book before. My first goal was, "Can I finish a book?" Leanpub helped me achieve that goal. I honestly don't think, without Leanpub, I would have achieved that goal for my first book. I think it's that good of an iterative process. Even if I'm not sharing my manuscript with actual people and letting them buy it, it's still an iterative process if you're generating PDFs and constantly looking at new versions of it, in my opinion.
So yeah, they picked it up. And the writing process, I guess, is different than if you were going to write on Leanpub. There is an editing team, and you have to use their systems. So I did have to adapt to that.
For instance, I believe they use Microsoft Word as the writing tool with some custom templates and things for code. They were able to take the manuscript or the PDF - I don't remember which? - and generate that into their format. So when I got the assets, a lot of the original book was already imported. The goal was just enhancing it and making some changes based on feedback of what they wanted to change about the original book.
Len: In addition to this Frontmatter Podcast, which - for those who might not know. "frontmatter" is a kind of technical publishing term for some of the stuff that comes at the front of your book.
At Leanpub, we've also got a podcast called Backmatter, which is about the publishing industry, the book publishing industry in particular. Just the other day, I was interviewing someone who writes a really great blog about authors negotiating contracts and things like that.
It's actually something I haven't asked on this podcast before, but what was that process like when you - I mean, presumably you had to sign a contract with Apress. And without asking you to give up any of the details of the contract, how did that process go? Did they shoot you a kind of like, "This is our standard contract," and did you ask any questions back?
Paul: Yes, I definitely asked questions. Because when you're signing a book contract, there's advances involved and other payments. For instance, I believe O'Reilly's a good example of this. They have their online library, and I'm sure that they compensate authors for being included in that digital library. Apress also has their own digital library, or maybe it feeds into O'Reilly's? I'm not actually sure. Because I do know that my book is available to the O'Reilly online subscription. But regardless, they do negotiate and pay you those royalties as well for being included in that.
I guess they sent me a couple of contracts, and I looked over them. I would say that I was a little hesitant, because I've always kind of been entrepreneurial and independent. And I knew that with this agreement, I faced a few constraints. For instance, I had to retire my book [on Leanpub]. And I couldn't market my own product. It was now out of my control, as far as trying to sell my book directly to people that would read it. I can still promote it obviously. And a lot of times, for a smaller author it's still up to you to promote this book, even though it's now -
I guess one of the illusions I had is originally, when publishing with a publisher, I had this perception that they would take care of all the promotion and marketing. And honestly, I actually don't really have a lot of view and insight into that process, or what is being done to market the book? It's obviously a smaller, niche title, compared to some of the other titles, etc.
But yeah, there was just all these considerations. And finally they sent over like the final contract, and I signed it. That was it really.
Len: Thanks for that great story. I think it's really interesting for people to hear about what happens after you get that exciting approach from a publisher - that there's a real kind of dotting the T's and crossing the I's, as I like to say, business work.
You reminded me of - I went to something called, Book Expo America, I think it was as long ago as 2013 now. And there was one panel at a boring time in a boring corner of the conference centre devoted to self-publishing. And Guy Kawasaki, who's a relatively well-known guy, was up there talking about it. And he said, "The last time I approached a publisher with a book idea, they said, 'So how are you going to leverage your social media platform and your one million plus Twitter followers, to help sell your book?"
And he said, "Well wait a minute!" He was being a bit tendentious in the way he presented it, but he said, "If this lifetime I've spent building up a following out there in the world is going to be the primary basis for the sales of my book, then what are you doing for me?" And for him, that for him was reason enough to go independent.
Of course people should know that, working with a publisher, a good one actually does do a lot of work for you. A good one does take care of a lot of things for you. A good one does elevate your profile. And so there are lots of good things that can come from it.
But yes, it's a very common experience for people to think, "Well now, all of a sudden there's going to be a stage with me in the middle of it, and my billboard's going to be up by the freeway in LA." And that is not the case for most -
Paul: I will admit naively that I did check a Barnes & Noble, just to see if maybe it was there. Again, this is a very niche topic, and it definitely wasn't there. A lot of times in Barnes & Noble, you're going to see like, Beginning Java, and just really boring, simple topics.
But I guess, just really do your homework, and make sure that when you're going into a contract, that you set realistic expectations with yourself and with them. Ask those questions, "What is the marketing plan for this title?" And just figure all those things out, and make the right decision.
Len: Nowadays actually, if you're an author, you might be asked to provide a business plan for your book as well. I don't know how common that is with technical books, because it's probably a lot easier to do some research and hone in on where a technical book should be marketed and to whom, than it is, says, for a book about vampire werewolves or whatever.
It's a real business and it's real work. It's something to keep in mind - that it's going to be exciting at times, and it's going to be boring at times. And it's going to feel a little bit risky at times as well.
The last question I always like to ask authors on this podcast is: if you could think of one thing that you could ask us to do to make Leanpub better, what would that thing be? Maybe building a feature or fixing a bug.
Paul: I did put a little thought into this, because I know that you ask this question. But I'm kind of drawing a little blank here. I did have a really good answer though.
Paul: Just forgot it.
Len: Okay. Well if you remember it, let me know.
Paul: Oh, I think I do. S
Maybe I'm just not checking close enough. But some marketing data - I know that you have some analytics integrations. But maybe - and again, I don't know the full details of this - but maybe having more data about the readers. I think it would be interesting to just know a little bit more about my reader from the dashboard.
I don't know if that makes sense to you at all. But maybe even just like having their name and knowing who they are.
Len: That's actually a really interesting, kind of "deep Leanpub" question. I'll try answer it relatively briefly.
We do have Google Analytics integration, and that can be really useful. But Google Analytics can also be kind of a bit tricky to relate to appropriately in my - this is my personal opinion - I've had this experience where if you show charts to people, they tend to assume a one-to-one correspondence between that chart and the reality behind it. It's a very common, normal human reaction.
For example, in the investment world, a client will come in and say, "Why should I invest in this stock?" And they'll say, "See this line going up? Let me just extend it out another three years."
And when you see that line going up for the next three years, people really - I know it sounds like an exaggeration, but people really do believe it, because they saw that chart.
And Google Analytics is actually really complex and really tricky. It's an art, not a science, using that. So I just want to caveat what I'm saying about analytics with my - I actually do have a kind of skeptical relationship to them myself. They're very important to have and to use and to work with. But everybody should understand that things aren't always going to match up day to day, if you know what I mean? Like what Google Analytics shows you happened a month ago, the next day it might show you something different for that very same day, because something changed, or some new information came in. So that's just one thing that people need to keep in mind when we're talking about analytics.
Another really interesting thing is, with respect to internet commerce and particularly with selling your own things - we often get people asking, "Can I get the names or the email addresses of the readers?" It's funny. One response is to say, "If you went and bought a book at the local book shop, would you want the author to get your email address? Would you expect that?" And you'd be like, "Well no, I would not; I wouldn't necessarily say no if they asked." But certainly, it's not your expectation when you buy a pillowcase on Amazon, for example, that the pillowcase seller is going to get your personal information.
But it is a natural question to ask, because Leanpub is in that world of handling things yourself and being self-promoting. And so our way of kind of managing those two competing expectations is to give readers the opportunity to share their email address with the author when they buy the book. That's one of our responses.
Paul: Is that possible today?
Paul: Oh nice.
Len: Unless I'm wrong about something, it's been a while since I've looked at that. But when a book is not published yet, you can actually choose to do it at that step. And I'm 99% sure you can choose to do it afterwards as well.
Paul: That's what I was going to say - from an independent writer's perspective, yiou need to build up your audience to support your future work, so you're not starting from ground zero every time.
It's not that I would want to spam people. But I would at least like to just let them know, like, "Look, you bought one of my other books;" in a kind way, "This is something else I'm working on that I think you might be interested in." But there is a lot of responsibility on the author's part to not spam people and take advantage of that.
Len: Exactly, exactly. And actually this something we put a lot of thought and work into.
One other feature that we have is a kind of double-blind system that lets you email your readers when you update your book. So if someone has bought your book, they can opt-in to receiving update emails from Leanpub. So from you, via Leanpub. You don't actually have to give them your email address, and they don't have to give you theirs. You can actually still contact all your readers about updates to your book.
Paul: Oh, that's interesting.
Len: It's there because like a lot of authors, they're like, "I want to communicate with my readers, but I don't necessarily want them having my email address." We also have Mailchimp integration as well.
Paul: Oh nice.
Len: So you can do that, and I'm actually - because I want to get this right, I'm just testing this process right now of buying a book, because it's something we're always obviously iterating on. But yes, establishing that connection in a transparent way - if people want to do it.
Yes, we've got "share my email with the author" as an option on what we call the "post-purchase page."
Paul: Is it unchecked by default?
Len: It's unchecked by default.
Paul: I think that's the right choice.
Len: It kind of has to be because of GDPR. Actually, "share email with the author," was always opt in. However, before GDPR came about, being emailed about new versions of your book was opt-out. You were automatically opted in to emails that updated you about new versions. We have a very opt-in culture, and so we only made that decision because of something unique to Leanpub, which is that books are actually being published in progress.
If someone buys a 10% book and doesn't have a Ph.D. in Leanpub, we don't want them to have to learn where to go to make sure they get an update for that specific book. We actually felt we were doing them a service by doing that. We were not giving out their email address to anybody or anything like that. But now everything is opt in, which is fine.
Paul: Yeah, that's cool. Thanks for the insight.
So are you also saying that like if I create a new book, that I could email that other book - all the readers and just say, "Hey, I've launched a new book," or is that outside of the like -?
Len: So, it's not formally sanctioned.
Len: But authors do do that. And we think it's fine, and readers like it. I would say - that is something you would do once. So, if you've published a new book and you've got this existing set of readers from a previous book, you say, "Hey," I would say it's okay to go ahead and send one email to them.
And conventionally, that ought to include coupon with a discount for the new book. That's definitely something you want to do. Because people love getting coupons, they love getting discounts, and you want them reading your new book.
Paul: Yeah, I definitely think too on the writer's side - you really have to be sensitive, tegardless of laws - just be sensitive to people getting a ton of emails and spamming them. Because it's not going to help you in the end. It's in your best interest to try to build an audience, but do it in a way that's not spammy.
Len: 100% yeah. That's something that's just - I've been at this for years, and certain people have certain kinds of personalities, that come along. And we have had people take advantage of the freedom to email authors and spam them. We stop that when we see it happen.
Len: So for any Leanpub readers out there listening, don't worry - if someone starts taking advantage of that option, then we put a stop to it.
Thanks for giving me the opportunity to talk about that. That's actually something that's a really important part of Leanpub, and it's a little bit hard to describe in words or just with a presentation of features. So, thanks for giving me the chance to talk about that.
Paul: You're welcome.
Len: Thanks. And thanks for taking the time to do this interview, and for being a Leanpub author.
Paul: Thanks Len, I really appreciate Leanpub as well, and I wouldn't be where I'm at today without using Leanpub. So I do appreciate it very much.