ÜBER DIESE EPISODE
Discuss this episode in the Muse community
Show notes00:00:00 - Speaker 1: No one would ever write a blog post or a book by hand or on a typewriter in 2023. Yet reading still pretty much takes place in the physical world, at least nonfiction, 90% of nonfiction reading is still paper books, and so our lofty ambition would be, we’ve created such a better reading experience using software that people are motivated to switch and read digitally.
00:00:28 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac, but this podcast isn’t about Muse the product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here today with guests Dan Doyen and Tristan Holmesy of ReadW Wise.
00:00:44 - Speaker 3: Hi, I’m Tristan, co-founder and technically CEO of ReadW Wise.
00:00:49 - Speaker 1: Excited to be here, Honored to be a guest, huge fan of the podcast.
00:00:54 - Speaker 2: And I understand you two had some fun with Falcon recently.
00:00:58 - Speaker 3: Yeah, that’s right. We were just off on a team offsite in Ireland.
We’re a remote company, so we try and get the team together about twice a year, you know, with scheduling and all that.
We’re about 14 people now, so getting 14 people out of one place is a little non-trivial these days, but we chose Ireland because we have an engineer. who already lives there, so you can kind of give us a good local experience.
And as part of that, we had a fun little falconry event where, you know, you have the little glove. I think you’ve done it before, Adam, and the falconry instructor puts a little meat on your glove and then the birds fly onto your glove and eat the meat.
00:01:38 - Speaker 1: Dan, is that a good overview of, yeah, we were able to play with a falcon, a hawk, and 4 breeds of owls.
00:01:43 - Speaker 3: Yeah, so the fun part was the first owl was like this cute little, I think it was like a snowy owl or something, Barn owl, oh, barn owl, OK.
So we take turns each like having the owl fly onto our glove. It flew on to dance, I think pretty successfully, and then we moved on to the next person, I think like one of our engineers or something, and instead of the bird flying onto the glove of the engineer, which had me, it flew back. On to Dan’s glove, which he wasn’t even holding properly or anything, and kind of gained this funny attachment to Dan. Then the instructor was like, Oh, that’s weird. Grabbed the bird and was like, OK, go over here. Go over here. He eventually got it onto the engineer’s glove, and then we did the next person, and the owl again flew onto Dan’s glove. And then that basically repeated for, you know, the next like 10 minutes until Dan had to like hide his glove and basically hide from the bird before it would stop flying to him, so.
00:02:33 - Speaker 1: Yeah, I grew up reading My Side of the Mountain, so I fancy myself a bit of a bird of prey expert.
00:02:40 - Speaker 2: Missed your calling as a bird whisperer. Yeah, I briefly had the chance to do the glove thing with the yeah, I think it was a falcon, and they’re just obviously really beautiful creatures, also very alien in a way, the way they move and the way they Obviously feathers and all this sort of thing, and obviously we see birds in our daily life, but birds of prey really feel like a different thing, I guess, and being that close and being aware of the weapons, you know, their claws or talons, I guess they’re called, and their beak and that sort of thing. It’s just, yeah, it can be a powerful experience.
00:03:15 - Speaker 1: Yeah, the descendants of dinosaurs.
00:03:18 - Speaker 2: Exactly right. And tell me a little about Reidwise.
00:03:22 - Speaker 3: Sure, so Readwise at a high level, we basically make software that helps people read better.
There’s a lot of ways we do that.
Most recently, we’ve been working on this app, which we call Reader or the Readise Reader, which is this piece of software which lets you read basically any type of content from PDFs to books, to articles, to YouTube videos, including their transcripts. To newsletters, to Twitter threads, to a lot more. We let you read that stuff, but more importantly, kind of save it, highlight it, and just kind of get the most out of your reading. And before we built Reader, we also built a slightly more niche app, which we now call ReadW 1.0, which basically helps you retain more from your reading and kind of manage all of your digital highlights.
00:04:06 - Speaker 2: And could you tell me a little bit about the journey you each took in your careers that led you to this venture?
00:04:11 - Speaker 3: Yeah, I think the Re Wi story really starts with Dan, so he can probably pick that off.
00:04:15 - Speaker 1: Yeah, I’ll start. My journey was a little bit more non-traditional than Tristan’s or probably the typical guest on this podcast.
In high school, I was very interested in computers and entrepreneurship. I actually had a web development agency.
This is in the late 90s, early 2000s, when every Main Street business was realizing they needed to have a presence on the World Wide Web.
As an expat in Germany, you might find it amusing that we called the company Glowing Pear, because we were studying German and learned that light bulb in German is Glue Bena. So that was a funny name.
But I went to school to study business, not realizing that studying business is really finance, so I took a 10 year detour from software and entrepreneurship to go to Wall Street, but then in my early 30s, I had an early midlife crisis, quit my job, sold all my things, and Traveled the world for a little over a year.
It was during that time that I became a power user of Kindle, because we were backpacking and couldn’t really lug around all these books.
And it was also during this time that I was reading about one challenging book per week, and I got really frustrated with the fact that I could barely tell you the name of a book I’d read a month ago, nevertheless, the key takeaways.
So, when that frustration hit me, I was just ascending the learning curve of this challenging flashcard app called Onki, and I had this idea, oh, I’m taking all these highlights while I read in Kindle, not doing anything with them. What would happen if I put them into Anki and review them for 5 minutes every morning?
00:05:46 - Speaker 2: Nke just briefly is kind of the original tool for thought in some ways, a space repetition system that basically uses this technique to help you remember things better. Beloved by language learners for sure, but also could basically help you remember any knowledge.
00:06:02 - Speaker 1: Yeah, Onki is a very powerful piece of software, but it’s a little bit hard to use. I had to read like a 40 page PDF to kind of get up the learning curve.
So this sabbatical afforded me that opportunity to learn it. So, yeah, I did a prototype where I wrote a script that would import my Kindle highlights and then I would review them for a few minutes every morning.
There was no commercial interest here, this is purely a hobby, just a personal life hack, but I really became interested when Not only did it help me remember the books, but there were all these higher order second level benefits that I hadn’t anticipated, and that really opened my eyes to what just I now call reading tech or reading technology, which is this idea that the software is eating the world, but it’s barely scratched the surface on the practice of reading.
Um, so this was in 2016, and I was in a place where I was looking for what to do next, and that kind of led me to Tristan.
00:06:57 - Speaker 3: Yeah, I have a little more traditional background than Dan, I guess, for software founders, I suppose.
I was studying computer science at the University of Waterloo. I’d worked at a couple companies, maybe like some startups, a notable one might be Stripe, and another Superhuman. I was actually doing an internship at Superhuman.
Even before that, I had a little bit of a background and kind of reading technology.
I guess it started when I was working at Stripe, you know, we had these brilliant founders, John and Patrick Carlson, and they’d always talk about how much they’re reading, how much they love reading. How beneficial it is for you, how it helped them form the company, how it helps them be successful, and I was kind of struck by this weird dichotomy that like here were these like super high tech founders who rely on and love books so much and find them so beneficial, and obviously I agreed, I read a lot too, and yet, you know, they were reading basically paper books, there was basically no innovation whatso all. From the practice of reading from what, like, their grandparents or people 1000 years ago would have done. So, I found that pretty interesting, and that kind of got me onto the vein of reading technology.
So I had my own side project, similar to Dan, which I called Reading List.io, which was a slightly different tact, but basically, I was trying to build a tool which would help you prioritize. what you want to read. So not discovery and not really trying to be social like Goodreads or anything, but myself and a lot of people I knew just had lists of books they wanted to read in a text file or Amazon card or something, like hundreds of books, but they had no good way of prioritizing them, analyzing that list, and deciding what to read next. So I actually posted a comment to Hacker News, I just on some random posts to do with reading. And I left my email, I mentioned I was working on this product, and Dan shot me an email, which was how we first met.
And then I happened to be living in San Francisco a couple months later, working at Superhuman, and Dan was also living in San Francisco, so we actually met up in person, and we became friends and decided ultimately to start on the first version of Reid Wise way back then in 2017, and yeah, that’s how we got started.
00:08:54 - Speaker 2: And how is this vision of reading tech evolved since you joined forces?
00:09:01 - Speaker 1: In some ways it stayed the same.
Our initial mission, I remember vividly being in San Francisco with Tristan in 2017, we formed the mission to improve the practice of reading by an order of magnitude using software.
That’s still our mission, still our vision.
The way we conceptualized it is we broke the process of reading down into 3 stages before you read, while you read, and after you read, and we hypothesized that if we could double the benefit in each of those, we’d get 23 power or an 8 times improvement which would round up to an order of magnitude.
So, we decided to start with actually after you read, based on my experimentation with putting Kindle highlights in Anki and the profound benefits I was getting from retaining more of what we read.
We found it was a pretty salient problem, like, we could talk to most people and be like, hey, have you invested 10 hours in reading a book and, you know, ever get frustrated that you are nodding your head the whole time you’re reading it, and like, wow, this is amazing, this is gonna change my life.
But then in a month later, nothing happens. A lot of people resonate with that, and There really was nothing else out there trying to provide a solution to that problem.
So, that’s where we started with Read Wise, what we call now Readwise 1.0, and it’s a very niche product, don’t get me wrong, but people who like it tend to love it, and it’s very sticky, and they use it for Years on a daily basis, and that was kind of the platform for us to move backwards through the process of reading with our newer app, which we call Reader, we were now able to get into while you read and start innovating there, and also to a lesser extent before you read.
00:10:46 - Speaker 3: Yeah, and there’s a long journey between us kicking off on that first Readwise 1.0, help you remember more product and to even when we started Reader, but yeah, a long slow journey, but, you know, we’ve been working on it for basically exactly 6 years now.
00:11:02 - Speaker 2: Our topic today is read later apps. Now, in this framework you’ve already described, this refers to, I guess, kind of before and during reading. This is an area I’ve been interested in for a long time because I have used a lot of Rela apps over the years, starting with Pocket was the first one I fell in love with.
And indeed that brought me to your product, Reader, which is looking for that kind of perfect relator app. And so I thought it would be interesting to talk about the history of those and other approaches to this, but particularly within this larger vision that you have about reading technology and improving all stages of this.
So maybe we can start with just how you both think about the category of rel apps and how you think about why you wanted to enter that category.
00:11:50 - Speaker 1: Yeah, for sure. So, starting with the history of read it later apps, there were really two prerequisites that were required before that category emerged. The first is kind of obvious, but the internet and This profusion of permissionless content, notably in the form of blogging, you really needed that content out there before there would be anything to save to read a later app. And then the second innovation was obviously the smartphone. This is the first time that computing devices were less about productivity, right? Like a personal computer is more about doing work. Of course people would play games or Watch movies on a computer occasionally, but it was really productivity first, and the mobile phone, smartphone was a consumption first device. So with those two prerequisites in the late 2000s, we saw the first read it later app. There’s some controversy as to who came first, but according to our conversations and reading of the history, it seems like Marco Ormant created Insta paper. And was the first person to kind of check all the table stakes boxes of what makes a real later app, need the ability to save web pages, to read later from both your computer and your mobile phone. You need to parse those web pages into distraction free clean HTML and then you need the ability to read those across devices. So he really kicked off the category with Pocket as a fast follower, and they really kind of dominated the category. There was a lot of enthusiasm behind these. I think Marco became a little frustrated with the whole competition with Pocket, so he sold Insta paper to a venture capital studio in New York called Betaworks, and they took the baton and continued to grow the platform while Pocket raised a bunch of money. And continue to grow the platform. But then around like 2015, I think they reached an asymptote in terms of their growth and kind of put these apps into maintenance mode. Betaworks spun Ins the paper out to Pinterest, where it kind of lived dormant for three years. Pinterest then spun it back out to the guy from Betaworks who ran it in 2018, Brian Donahue, good friend of ours, a lot of respect for him. And then Pocket was acquired by Mozilla, which is why you see Pocket built into the Firefox web browser. I share that history because that’s part of the reason that we entered this category is because we love these apps. I’ve been a user of Insta Paper since, I think, 2011, I tried to go back and figure out when I first saved a document there, but from about 2015, 2016 on, they were just maintained as opposed to adding features, so we felt like there was a little bit of a void in terms of innovation and continuing to build on to the great foundation that they started. So we saw an opportunity there, at least for our user, which is very much a power user to enter that space and kind of carry the baton forward.
00:14:55 - Speaker 3: Yeah, and you can kind of take the path to read it later apps forward from us, we kind of start a new one.
I’d say the existing ones this paper and pocket basically been left alone, just kind of maintained, but you can also go a little further back, it’s kind of interesting, and this is something that Dan actually has pointed out to me and we’ve kind of discovered, or at least discovered the significance of only like rather late into our journey to Reader, like, there was a fundamental activity that came before Read it later apps, which was, as you probably know, Adam bookmarking.
There have been bookmarking apps, basically, I think, as long as the web browser has existed. I’m not really sure what the first one was probably built into Netscape or something, but you know, there’s this fundamental habit of just bookmarking a web page or URL that you want to come back to in the future.
All major web browsers have this built in, there’s a lot of dedicated bookmarking apps. Such as pinboard and many others.
What’s kind of interesting is that fundamental activity, saving a link kind of forked when the smartphone came out.
So, One Direction is the one that Dan mentioned, which is that people took bookmarking, added in, you know, distraction free reading, added in the cross platform syncing, and you kind of got real later apps. There was another fork though, which was pretty interesting, which was basically what Pinterest did.
Pinterest at its core is bookmarking. It’s much more visual bookmarking. It’s a very different market from the read it later out market. It’s a lot less of a focus on maybe like the traditional type of like blog post reading that would happen in its paper rather, it’s a lot more focus on inspiration, stuff like saving recipes, but at its core, that’s another fork of bookmarking, so it’s kind of interesting to see.
And what’s also striking about this category is, we’re not venture successes at all.
Its paper wasn’t trying to be one, pocket was. And I’m sure the exit was still successful, but it hasn’t become this like household name, whereas Pinterest really took that fork and it was massively successful with it, which is kind of an interesting tidbit.
And of course you could maybe view a third fork as social networking apps, especially if you focus on news. And just a more social angle, those are also being massively successful and at their core, a lot of what people are doing is sharing bookmarks. So there’s some kind of interesting history there, we could probably nerd out about the history forever, but that’s probably as deep as we should go.
00:17:07 - Speaker 2: Yeah, I agree. It feels like the fundamental building blocks or primitives that eventually became what we now think of as relator is bookmarking, obviously the web and as you said earlier, Dan, the sort of permission free, I can just click a link and start reading it style that exists on the web, putting paywalls aside, of course.
And then I also feel like RSS readers and the sort of blogosphere circa, you know, mid 2000s, maybe as part of this equation as well.
But looking at the kind of relative enthusiasm for those early movers and paper and pocket and then how they both seem to peter out and eventually go into maintenance mode, it does seem like this is a beloved category for a certain class of person, 3 of us included, but that class of person there just isn’t enough of to make a venture scale business out of.
And so, yeah, when things cap out and then they can’t give the proper returns to their investors, and I seem to recall pocket kind of thrashing around a bit and adding social features and adding this, that and the other thing that I think power users who are focused on their reading experience didn’t want in hopes of, yeah, trying to achieve that scale. What have you learned from this history, and maybe it’s partially just how to think about the market, but also, what are you gonna do to avoid the, you’re walking down a road and you see these bodies alongside of it. What does that tell you about the dragons that lurk in the bushes?
00:18:34 - Speaker 1: Yeah, well, the first thing is raising venture capital into a reading app is difficult, which is one of the core reasons back in 2018 we actually published a blog post that we referenced all the time. We decided to bootstrap readwise, meaning, you know, fund it from Revenue from our customers as opposed to venture capital, that was one key lesson we learned and we think enables us to build for the long term. Tristan, you wanna take it from there?
00:19:00 - Speaker 3: Yeah, well, the other is kind of the fact that we look at the history at all, and we looked at similar startups when we first started Read Wi, similar companies that had tried to build on top of the Kindle platform, or what have you, you know, I think there’s that quote from Alan Kay, where he’s like, computer science is like a pop culture, where no one ever looks back in time at all.
And we’ve actually just gotten a surprising amount of value, just by looking back, you know, looking at the history of Insta paper and pocket, how it turned out, like what People liked about those, what they didn’t, what growth strategies worked for these companies.
It just says a meta point that’s super underrated in startups.
And you know, we’re not near one of the internet here. This isn’t like 1995 or whatever.
There’s a lot of data to go back on, and that’s not to say that means these ideas are dead ends. Obviously a lot of ideas that didn’t work in the past can now work because of better distribution or better internet speeds or hardware or whatever, but there’s just a lot of value to going back and looking at those.
00:19:52 - Speaker 1: Yeah, I think another lesson is from a business model perspective, they were both trying to reach a social scale that could be funded through ads and just having so much attention and eyeballs. I think that’s a pitfall that we avoided by making premium software.
Another thing we noticed is It’s hard to get accurate estimates of how many signups or users they’ve ever attained, but it seems like around like 60 to 80 million people have tried insta paper pocket, yet I would venture, there’s probably a million active users, so there’s some sort of huge drop off where people fail to adopt the core behavior.
That’s definitely not something we have solved. Let me be very clear, but that is one of the things that we aspire to figure out and solve at some point.
00:20:41 - Speaker 2: I do have to wonder whether there’s sort of a gym membership effect here, which is people aspire to read more, to engage more thoughtfully with, you know, whatever content they feel is important to them. But in the end, the low friction path is let the algorithm pick out a video for me to watch on YouTube or Netflix, for example. I mean, the entertainment and general kind of media consumption options we have at our disposal in this day and age are just unbelievable, and so you have to be fairly dedicated to stick with that, I think.
00:21:10 - Speaker 1: Yeah, we love that fitness gym membership metaphor. We use it all the time internally to describe what we do.
00:21:18 - Speaker 3: Yeah, and it’s pretty motivating, right? Because we are often eating time from, you know, somebody scrolling reels on Instagram, or scrolling TikToks or scrolling through their Twitter feed.
We aspire to do better than that, and it’s very motivating when you know that you’re helping people read stuff that they’ve consciously picked out. It’s a lot harder, absolutely, it’s a huge challenge and to be clear, we lose to these.
Addictive social media apps all the time, but we can feel good about building a future which really grows engagement, which really makes the app sticky, which really, you know, sends the user a push notification every morning, and we don’t have to feel bad about it, and the user will generally leave a session of the reader app or the Read Wi app feeling very happy about the time they spent. And I think While it is a little bit of an uphill battle, just like a gym membership. Once you can do it, I think people become very loyal customers. They have very high retention, and they really like coming back to you. It’s just a a lot harder, but, you know, in the same way, we can feel good, just like a gym membership. Maybe most gym members won’t end up using that, you know, you can go and invent like a Barry’s boot camp type of class. Or something, or you can go invent a new workout machine or workout process or workout plan, which really does help people actually get better outcomes and read more and spend more time reading and feeling better.
It’s super motivating to get up every morning and work on that problem as opposed to how can we make reels, you know, 1% more addictive and extract, you know, 5% more ad revenue. We’re not like these huge social media haters. We go on these tirades, like they’re tearing apart society, especially Twitter, definitely has its place, and there’s a lot of value to very like low information latency communication and stuff like that, but there’s also a place for long form reading that there’s probably a suboptimal amount going on there if you would ask most people how they’d like to spend their time.
00:23:01 - Speaker 2: Well, actually, since we’ve mentioned social media a few times and I think this is probably also related to that proto aspect of linked discovery, which was RSS feeds, for me, there’s actually a very natural pairing between the social media that I do use, which includes Reddit and Twitter and Re later because I find that when I’m in that linked discovery mode of scrolling or grazing at the content. It’s a little bit too disorienting to then dive really deep into a longer article.
And actually I noticed this in my career as a writer on the web, and particularly when I’m writing content for Yeah, like a blog somewhere where we are thinking about, OK, people are going to follow this link from Twitter hacker news, whatever, and we want to keep them engaged and there’s somewhere around 2000 words is kind of like your maximum.
No matter how interesting it is, people are going to drop off, not because they’re not interested, but because they’re not in that mindset of going deep in the long form reading.
And one effect, you know, if you don’t have a tool like this or some kind of discipline built into your consumption habits, is that just gets lost, you know, maybe you bookmark it or you leave it in an open tab, you know, I’m going to read this later, and I think that system doesn’t often work that well for people, but for me, it works really well.
To have a place to put something that I want to read, I do want to engage deeply with, but I want to be in a place and a mindset where that’s what I want.
I’ve just settled down into my seat on a long airplane ride, and yeah, of course I can get a book, but I also might want to get out a long form web article, for example. How do you see reader fitting together with, yeah, social media, the linked discovery problem generally, and how does that fit in also to that framework of the, you know, before, during, and after reading.
00:24:49 - Speaker 1: Yeah, there are a lot of interesting topics there. I’ll start with first, the type of reading that we’re focused on.
So in books, which is where we started, believe it or not, before read it later, they typically bifurcate reading into nonfiction and fiction. We think that’s a little bit of a crude dichotomy. It doesn’t really apply to this reading.
We break it into reading for betterment and reading for entertainment, and our mission is to improve the practice of reading for betterment by an order of magnitude.
Reading for betterment might be learning knowledge, learning know-how, which would be like a skill, trying to better your career, your relationships, listening to a podcast in your industry like Meta Muse, reading a newsletter about your career. Those are examples of reading for betterment.
Reading for entertainment would obviously be the kind of reading you would do instead of watching Netflix, like maybe reading Harry Potter, listening to a fun audiobook about science fiction.
And news is one of these that kind of falls somewhere in between. In many cases it is just a form of entertainment. Occasionally it is a form of reading for entertainment, so we often see it like things blur for us when we’re talking about news and RSS.
When we started Reader, we spent a lot of time trying to come up with these really robust abstractions that would enable us to build for a long time, and we tried to anticipate all the pitfalls and the dead ends and the idea maze. I think one area where we were a little naive was the pairing of read it later with RSS. That was probably one of the hardest challenges.
For me, it’s one of the hardest challenges we faced, because you have so many different RSS use cases.
So, you have this old school generation of RSS readers, people who are around back in the golden era of Google Reader, who are just absolute infovores. They’re getting like 1000 new links a day, and they just want to churn through them. We haven’t yet built our RSS feeder to accommodate them. We’ve really Built it towards the more modern RSS reader, which is born out of substack and email newsletters, where you’re getting maybe 2 or 3 long form pieces per week, and that’s more the volume you can deal with. But obviously RSS has been a category that had a lot of enthusiasm in the late 2000s, early 2010s, but from our perspective, I think most people would agree, social media kind of replaced or supplanted RSS. So yeah, we’ve not been trying to go back and recreate what RSS used to be and kind of fight against that current. We’ve really been building for the more modern RSS use case, which is less about like getting your TechCrunch and yournggadget, 100 links a day, and more about your substack writer who posts 3 times a week, more to that like blogosphere era.
00:27:40 - Speaker 2: Substack is an interesting one to talk about.
I think Reader and Substack at the moment are sort of my two apps on my phone that are the ones when I think, OK, I want to go for an in-depth piece, I have some time to sit down. I’m eating lunch, I’m, yeah, on the plane, I’m whatever, those are the two apps I’m likely to go to, but they’re completely different. Reader is part of, yeah, open web, open protocols, you can save any link. Indeed, you support media types outside of the web, including PDF and Video and others like you’ve mentioned, whereas SubStack is a closed network that includes the publishing, the content, the linked discovery, the whole, you know, subscribe and follow the payment as well as now because they have a really nice mobile app, the reading experience. How do you think about, I don’t know, substack fitting into your world, part competitor, part adjacent complimentary product, I would imagine. Yeah, how do you think about that?
00:28:38 - Speaker 1: Yeah, I mean, we definitely have a lot of respect for those guys. The quality of content coming from them is off the charts.
One interesting thing that Tristan and I always talk about, and maybe he can expand on this is one of the opportunities we saw when we started working on Reader is, but for ins the paper and pocket, there’s really never been a reading app that’s been built for the reader.
Most reading apps come from the supply side, and they’re really Trying to benefit the creator of the content as opposed to the consumer of the content. So we saw that as an opportunity for us in a point of differentiation, where we’re putting the interests of the reader first, as opposed to the interests of the creator. Now, oftentimes there’s an alignment of interest there, but not always.
00:29:22 - Speaker 2: Right, you can think of Substack like medium before it as something where it’s a two-sided network, and they want to get the readers and they want to get the writers or the content creators and put them together, but even, yeah, for example, part of the substack, call it reading experience is that when you’re scrolling through an article, you know, it’s prompting you to subscribe to their newsletter, either to get the emails or to subscribe as and become a paying subscriber or even once you are a paying subscriber. then it still says, do you want to give this as a gift to someone else, that sort of thing. And obviously all of that serves the interests more of the platform and of the content creator, and it’s a minor inconvenience, so I don’t worry about it, but it’s obviously not putting the reader experience first the way that you can.
00:30:05 - Speaker 3: Yeah, and to be clear, there’s great value in serving the writers. I think they are an important part of the ecosystem, you know, with writers, there’s no reading, but just for us, we’re like laser focused just on the readers, you know, we don’t want to offend the writers, we’re not gonna do anything that takes money out of the writers’ pockets or try to hurt them at all, but at the end of the day, every day we wake up and we build software for the readers. We think about how does this reader want to spend their day, how do they want to spend their time reading, how will they feel good about their reading time after, and how can we help them do that? And ultimately there are customers too, we’re just very, very laser focused, and I think that allows us to go a little deeper in the IDAs of reading. We just solely think about how we can make reading better, and I think that helps us a lot. I think we’re pretty lucky to be able to do that. Of course, you know, it’s arguably a worse business model. Dan and I can go on and we have for days and days about the challenges with consumer sass and charging consumers money and how much higher the bar is there compared to enterprise and all the unique challenges like having churn, non-negative churn for your business. So there’s a lot of downsides to it, but at the end of the day, at least we get to have that benefit. So we try and enjoy it as much as we can, I guess.
00:31:13 - Speaker 2: Yeah, I’m generally a big fan of prosumer software and indeed that’s what Muses, but yeah, it comes with a lot of challenges. You get the fickle behavior of consumers and the desire not to pay any money. Often in a surprising contradiction where what they’re willing to pay for physical goods or experiences like eating out at a restaurant, don’t seem to match up with what they’re willing to pay for digital goods.
Happily, I think that has changed a lot and actually maybe this is to your point about your ability to succeed where some of the earlier folks didn’t, you know, I remember when Pocket experimented with, I became a paying subscriber, they had a, I can’t remember what it was, $40 a year or something. Subscription, I was happy to support them, but I think at that time, this would have been, yeah, 8 or so years ago, the idea of prosumer software paying subscriptions at that price point, which is kind of what you need for the number of people in your addressable markets. I was just like offensive, somehow and people were just like, you know, up in arms because they were used to getting all this free stuff from, you know, Facebook and Google and everything like that. Happily, I think that has started to change both as software developers, especially in the software developers realize subscription. are a way to make a sustainable business and do well by your customers and increasingly I think customers are starting to recognize that.
But yeah, when you compare to the ease of getting a business, a B2B customer to pay, where if you can do something to improve their efficiency and help them do their business better, they’ll happily pay for a tool, an individual will hesitate on that a lot more.
00:32:47 - Speaker 1: Yeah, it’s always funny how I’ll slap down the corporate card to buy a $30 a month form building software without even thinking, but many times we’ll get users right in that this is kind of like a family decision. They, they have to talk to their significant other about whether or not they can afford this expense at dinner. Completely different psychology around these expenditures.
00:33:09 - Speaker 3: Yeah, and while you’re right that there is a lot more willingness to pay and subscriptions have become a little normalized, I think, whereas in the past, you might have got more of a comparison to Google or to Facebook and be like, oh, online software should simply be free. Now we get a lot more of the comparisons to Netflix or Spotify, and they’ll be like, well, Netflix gives me millions of videos, Spotify gives me unlimited music, and, you know, they cost the same per month as your product, so like.
How can you justify that? And of course the optimal amount of like pushback you’re getting from these customers is not zero. If you’re getting no pushback, it’s probably because you’re charging like something so ridiculously low that your company is not sustainable. So you kind of have to take a lot of that feedback and stride and be like, oh, well, if you value Netflix more than reading better, then, you know, you’re probably just not our target user, and that’s OK. Maybe you can go use the free pocket version and that’s actually better for you.
00:33:57 - Speaker 1: Yeah, the place where we succeed is when we’re dealing with someone who views reading not as a form of consumption or entertainment, but as an investment in themselves, almost like a form of education, and when it’s framed that way for them, the expense is a no brainer because they can get such a higher return on time invested in reading than they can otherwise. So that’s where we really win.
00:34:21 - Speaker 3: Yeah, and that is the sweet spot, right? I think there are a lot of apps out there, like, you know, Pocket is better for the price obviously, than Reader.
You could argue maybe like Pocket Earns paper has a very simplified, streamlined, very simple approach, and maybe that’s better for some people who just want something dumb simple, and that’s fine.
There’s a lot of aspects in my life.
I might prefer an app like that, but if you are someone like Dan mentioned who views reading as an investment, and you’re kind of coming into the same frame with it as you would a online.
Course, you know, they have these online courses that teach you to write better, to be more productive in your job. They’ll usually be like $3000 4000 dollars for a course.
And, you know, a lot of people consider that a worthwhile investment in themselves, and it probably is, it probably is worthwhile.
So for people who actually value that investment, I think we can say Reader is the best product. For those types of serious readers and people who are reading for betterment, and that’s kind of the sweet spot we aim to be at.
Again, because we’re bootstrapped, we’re not trying to get a billion users, probably like Pocket was trying to do, I would guess. We don’t want a billion users, we want the million, the hopefully someday 10 million people who really, really want the absolute best reading experience for productivity and betterment.
00:35:33 - Speaker 2: Now speaking of comparing to free alternatives, how do you think about what’s now built into the sort of iOS and Apple operating systems with there’s a reading list and the readability mode for websites, that’s kind of one tap away and yeah, it gets all these first party advantages in terms of it’s a single tap to say something to your reading list versus needing to go through a share sheet and set things up to reach your app. How do you find customers compare you? How do you think about positioning on that?
00:36:01 - Speaker 3: Yeah, that’s a great question. That actually speaks to like the main benefit of reader, you know, we’ve talked about we want it to be better, but how is it actually better than other ways of reading right now.
The main value prop that we pitch, we basically call all in one, and this goes back to comparisons to substack 2.
The main goal we had for reader as a product for the 1st 2 years of building it was that a user can save absolutely any type of content they want to read. As long as it’s reading for betterment, they can save that to readers. So, again, that’s from books to articles, to email newsletters, to RSS feeds, Twitter threads, YouTube videos. Basically, you can get all of that stuff into one place, so when you’re, you know, sitting down on a flight, like you mentioned, Adam, you have everything that you’re consuming in one place rather than say in Safari, you’ll just have your web articles, or on Twitter you’ll just have your Twitter bookmarks or something. The reader can support all of those things and more. That seems to be the thing that users tell us they like the best of our reader.
00:36:58 - Speaker 1: Yeah, this is kind of like a classic substitute. What’s a substitute for what you’re building.
And I will say the biggest substitute is just having a bunch of tabs opening your browser. And I’d be lying if we said we had figured out how, not with a power user, but with more of what we call like a normie user, we’d figured out how to persuade someone that it’s better to be saving those things to reader and aggregating them in one place and kind of taking control of that fire hose of content.
In reader, but that’s probably our biggest aspiration for the remainder of 2023, trying to figure out how to make that value prop more tangible and the onboarding experience to experience it much faster and smoother.
00:37:42 - Speaker 2: I’d be curious to ask about a few technical aspects of how you’ve built this product, and the first one that comes to mind is, yeah, let’s call it that readability mode or the parsing, the stripped down view.
You’re not just a bookmark where when I call up the article that then it’s displaying it exactly as I would see it in my browser. I get this simplified view, everything’s kind of in the same typeface, etc. and my experience with read letter apps has always been that.
Even a very well made 1, 80%, 90% work perfectly and then there’s also a pretty big list that worked pretty well, but for some reason, the first paragraphs missing or the image should be there that isn’t or there’s an image that’s actually part of an ad that is, and then on the far end of the tail there somewhere is articles that just don’t work at all or whatever and you need to open in your browser. How do you implement that parsing, whatever it is you call that part of the product.
00:38:37 - Speaker 3: Yeah, that’s a great question, and it is a really hard problem. It’s definitely one of the harder problems we had to tackle. You know, there’s a lot of secret sauce there. There’s a lot of just manual work over a long period of having the right libraries to do the right type of extraction, the right type of labeling, third party providers, machine learning. There’s a lot that goes into it, but I’d say there were Maybe a couple like interesting decisions we made that I think have made us pretty successful at this. Obviously, we still have parsing issues, and I’ll explain in a bit how I know this. Like, I think we have basically the best parsing of any read itator app that we’ve tried.
So the first major decision I think you have to make is, do you do the parsing on device locally or do you do it in the cloud? And we decided to do it in the cloud. There are a lot of libraries. There’s a pretty popular readability.js one that I think Firefox maintains that they use for their reading mode, and I don’t actually think they use it for a lot of pocket, but it is used for the Firefox reader mode, and who knows what else. Google Chrome has their own version too, that’s even a lot simpler than Readability JS, so we could have done it on the client, and there still might be situations in the future where we want to do it on the client, but We just found them really lacking. So ultimately we decided to join the cloud, which gives you a lot more ability to debug what went wrong, to improve your process, to fix the parsing from our side when it’s broken, and just really collect the data we need to build this ongoing process.
So that was one decision we made earlier on, which we really have no regrets on.
We do a lot of other stuff on the client, you know, our reader as an app runs what we call offline first, basically, most stuff can happen offline and the user’s client, but this was one thing where we’re really glad. We did it on the server.
Another thing we did early on, which I guess we just took for granted as like a software engineering thing to do, but has really helped us is basically, before we even started building parsing, we went into Readwise, we found the top 100 articles that people had highlighted the most. And read the most. And basically this is just like a proxy of the types of articles that our users would want to read. We went into Insta paper, we went into pocket, and we basically manually labeled every single one, like, did instant paper succeed at parsing this article perfectly. If it wasn’t perfect, what did it have missed? Did it miss some images? Did it miss some text? Did it include stuff it shouldn’t have included, and you can have different. Tables for these kinds of things, you know, including stuff you shouldn’t have included isn’t nearly as bad as missing content. So we label it that way, and it was basically just this giant Google sheet, very manual things that don’t scale process. But then when we were trying different prising solutions, we would just evaluate them against the spreadsheet, which really, really helped us. And now, you know, we can confidently say, at least with the types of articles that our users read. By this benchmark, we actually definitely outperform ins paper and pocket in almost all cases. Obviously there’s still a few that I will miss, but, and then again, we’re able to go onto that spreadsheet and prove the parsing and fix even more. So that was a really awesome decision we made early on, is just building that manual benchmark and manually going through early on and building that.
00:41:28 - Speaker 2: Yeah, it’s great to have like a really clear benchmark because there’s no such thing as perfection, but I’m reminded maybe of like the web standards acid tests or something like that where engineers and builders in general are really good at, you know, working towards a clear targets, but when it’s just like, I don’t know, try to parse most articles on the web correctly, hand wave, hand wave, that’s not an achievable thing or a measurable thing. So yeah, I can see why that would be a really nice way to concretely compare the approaches you’re taking. And also seems like a natural just integration test, basically.
00:42:02 - Speaker 3: Yes, so that’s the benchmark, and then the last thing I think we did that was maybe unique to us, I don’t know how pocket Instapa did it back in their day.
Instant paper was basically just Marco, so I know he didn’t do this, but basically we have a dedicated parsing engineer.
Started off just a role that one of our engineers took on part time, but now we have a contractor who basically works on fixing parsing issues full time.
We have a whole test suite. We know that like when we update parsing, it’s not breaking anything that was previously working, and we just have this engineer working full time on going through. We have a whole system where we have users report parsing issues, so that goes into this like database we And then we sort them by the things that are most read that are reported broken, and then things that are most reported broken by our users, and we’re able to just kind of privatize that way.
And so we still have an engineer going in every day and fixing the top websites, fixing the top articles that the user report are broken, and that has been pretty good. There’s still a lot left to do, but at least we can have this confidence that it is getting better over time rather than slowly decaying, which I think is the norm with this open web kind of stuff.
00:43:02 - Speaker 1: Yeah, to that point, it truly is a game of cat and mouse. There are some platforms out there, particularly the old school media outlets that really don’t want people to take content off the platform and read it elsewhere.
So, you may have good parsing for a month, but then something changes and you have to go back and fix it. So, it’s a constant battle, you’re never done. One final thing we did from a product perspective as opposed to, well, it’s heavy engineering, but from the user experience level. We also have a powerful browser extension that enables you to highlight the native web page. So we consider that our failsafe in the event that parsing fails, you can always open the original, and then if you have the reader browser extension installed, you can highlight on the native page. So that’s good for these parsing exceptions, it’s also good for instances where the original creator put a lot of effort into formatting or creating a reading experience that It is actually better than the distraction free clean experience. I’d say the distraction free is better 98 times out of 100, but there are some times where the website is like, truly unique and special, and you want to read it there.
00:44:14 - Speaker 2: Yeah, if you ever read like a bread Victor post or article, yeah, explorable explanations was the first thing that came to my mind.
But yeah, I also know that exactly some people put a lot of effort into the typography into the diagrams, so the things I actually want there are bespoke.
Experience, particularly if they made it work reasonably well on mobile.
It’s just as a default and it’s both the sort of actively user hostile aspects of ads and irrelevant junk that I don’t want to see and clutter up, especially a mobile screen, but also it’s just like, I don’t know, there’s many pieces of good content that are also on a website that just doesn’t have legible typography.
And I just want to be able to read it.
That’s all, and this, you know, basically pulls out the content and puts it into a kind of a standard size box that’s often better than whatever wild west is out there on the internet.
00:45:02 - Speaker 3: Yeah, and luckily for us, the web page you do actually want to read the author’s version of is quite rare, you know, like Dan was saying, I would say it’s, you know, definitely single digit percentage, often less, and then that actually extends to other format types too. For example, we support Twitter threads. A lot of people prefer saving their Twitter threads to reader and just being able to read highlight across tweets, for example, in the thread, be able to read it, you know, without having to scroll through and There is some cool benefits to Twitter threads where you can click into a specific tweet and see the comments, but for the most part, that’s better. And then even in PDFs, PDFs are kind of like notoriously annoying to read on mobile. You have to kind of like pinch and zoom to like read a sentence and then scroll it across.
00:45:42 - Speaker 2: The two column academic format was never made with the mobile form factor in mind.
00:45:47 - Speaker 3: Yeah, I mean, just PDFs weren’t in general, right? And so we do. Have a feature now where we’ll parse your PDFs basically into clean HTML. So when you’re on your phone, you can just switch to that. It doesn’t work great for graphic heavy PDFs, obviously, but, you know, if you’re basically just reading some text exported to PDF, it works a lot better. And so, you know, there’s really no shortage of benefits for the clean view. Luckily for us. Maybe in the future, all websites will be formatted so nicely and have such great interactive experiments. We’ll need to change that up. But for now, it works quite well.
00:46:18 - Speaker 2: Another technical area that listeners of the podcast will know I’m very interested in is everything having to do with sync, and I know you’ve mentioned there being offline first and maybe I’ve even heard you use the term local first or seen that in your marketing somewhere, but certainly coming back to that personal example of the reader app and the substack app.
Both do pretty well at allowing you to read stuff offline, but even there I can see where you put some effort into that that goes beyond what substack folks do as one small example that I run into pretty frequently, I read something on Substack while I’m, yeah, again, on a plane or in the elevator in my apartment or some other place where I don’t have network, and the archive button just basically freezes the app if you tap it, so you can’t archive an article while you’re offline.
You could read it, but you can’t archive it, whereas that does work for readers. So I’m curious to hear, yeah, how do you do the syncing? Obviously the cross-platform element is actually an important part of the relator experience because you do often read on mobile, capture on mobile, but the desktop is also really important. Tell me about all that.
00:47:24 - Speaker 3: Yeah, of course. So there is a lot there. I will say our app is in technically local first, and we’ve taken a lot of product engineer, especially engineering inspiration from what you guys have put out the Ink & Switch. So hugely thankful for that. It was actually really, really useful reading through all of that, and Reader isn’t. Technically, local first, I think by the proper definitions, your client will need to sync with the server to start. You can’t just start using it offline. For the first time you use a new device, it needs to basically sync some state from the server, but after that you can basically use it offline indefinitely.
And there are some things, you know, obviously syncing documents saved on other platforms, etc. parsing, all that stuff only works online. There are parts that require working online, but for the most part, yeah, you can do everything offline for as long as you want, and then just when you come back online, all your changes will be synced.
00:48:13 - Speaker 2: Well, I mean, it’s pretty fair that parsing only works online because if I save a web link, somehow. Now I don’t know, I had it in my copy paste buffer into my relator app and I’m offline. I can’t load the webpage regardless. So it doesn’t really matter if I can parse it or not.
00:48:27 - Speaker 3: Yeah, that was our thinking there too is there’s a lot of stuff which is just naturally paired with online activity anyways. Another thing that doesn’t work is adding an RSS feed that won’t work offline, where obviously you need to connect to the external RSS feed. So yeah, it mostly works. So that’s why we kind of tried to say offline first rather than local first. It isn’t quite the vision of maybe like some of the demo apps you guys have shown us, like an app where you can take notes, and that could just work fully offline and never need to connect to the server. It’s not quite that, but basically once it’s connected up front, you’re good to go. So syncing is actually interesting.
Believe it or not, we actually tried to use automerge was one of the things we first tried when I was first building the first version of. Reader. Unfortunately, Reader supports a lot of data. Our users will commonly save thousands, tens of thousands of documents to reader. And at the time, automerge performance was just too slow to load that stuff into memory. I do know there’s been like a whole new version of Amerge recently, I think, written in like RT or something, which actually might work great. I don’t know if we could switch to it at this point, but yeah, so we evaluated automerge, didn’t really work for us at the time.
We evaluated CRDTs, we’re like, oh well, you know, we could use some other type of CRDTs and actually because our app isn’t multiplayer, it’s really just single player. We actually just settle on a very simple syncing solution, basically, a user will make a change locally. The whole local state is basically just JavaScript objects, JavaScript arrays, etc. So what we do is we take the state before, we take the state after, we generate a JSON patch between the two, and we generate the reverse JSON patch, which is very important as well, and we bundle those up into an update object which we then cache locally on the client and send off to the server when it’s ready, and just the JSON patches which are There’s still going to be some conflicts sometimes if you do some stuff offline, then change the same data on a different client, but conflict resolution is very easy for us because it’s just the same person twice, so we can kind of just do last right, almost always wins. And so, yeah, Jason Patch’s simplicity for the win, I guess, has actually worked out great for us. Now, if we ever do build multiplayer features, which we’re not really planning on, but if we did, maybe that would bite us in the butt, but.
00:50:36 - Speaker 2: Now that makes sense to me, and I think the domain you’re in as well, almost all the operations that just come to mind, whether it’s saving a link, whether it’s archiving something, whether it’s highlighting something, these are mostly items operations, right? If I archive on my desktop, but I had previously done that offline on my phone, and then I come back online with the phone and that syncs up, just the two archive operations don’t matter that much.
So it seems to me like a really simple solution there is a good one, but ultimately is a syncing. Solution rather than a classic cloud solution, which is I don’t want to tap on my article to read just as I settle down in my comfy chair and get a spinner. I want the whole idea. I mean, I think the product brand pocket was an excellent one and instant paper also encompasses this. Both of them seem to capture the sense of like, it’s a thing you have or you can hold. Rather than the web is a place you, you go out to, you visit a web page, but I don’t want to visit a web page. I want to take this link and save it into my pocket or my instant piece of paper and have it. So then when I sit down to read, I know it’s there and I’m not subject to the whims of the network for that.
00:51:44 - Speaker 1: Yeah, and that whole notion of capturing or archiving or saving is another value prop of read it later that we haven’t talked about, but it’s very important to people to kind of snag this content and a place and time and know that it’ll be there when they come back, which you don’t always get with just the URL.
00:52:02 - Speaker 2: Yeah, I wonder also if there’s an element of personal curation here somewhat, which is one effect of the call the mainstream sort of digital media consumption places is that you typically have this stream of stuff that doesn’t belong to you in any sense when I’m browsing through TikTok. None of this is like mine unless I actually create it. It’s just a stream of stuff that’s started going by, and even something like my Twitter feed or whatever, doesn’t have that sense. I guess you can like your bookmark things there and hopefully those are retrievable later, but I think there’s something to, I want to pluck this thing out of Again, my late discovery mechanism, whether that’s hacker news, Reddit, Twitter, whatever else it may be, and say this is mine now, it’s something I want to read.
And then furthermore, maybe this goes to your kind of after reading part of the experience. I want to say I’ve actually highlighted some things because I’ve got some value from some of the concepts in this article, and these highlights are mine. The article was written by someone else, but these highlights were for me, the things that mattered or were relevant or sparked some insight in me. And then furthermore, then I can tag it as a favorite or something like that and be able to go and search that.
Later, what was that article I read, I think it was like a month ago that had this concept, I want to share that with someone else, but I can’t remember the name of the article, and searching the web for it is a much bigger haystack to search for that needle than just searching articles that I’ve read or favored.
So I feel like this curation aspect, which I think again is a downside, most people don’t want to do that curation work. They don’t want to curate even a playlist on Spotify, they just want to turn on the radio thing and just say play stuff I like for me, whereas maybe again coming back more to that power user, you’re investing in your reading experience. In the kinds of content that you want to read, and it’s worth doing a little bit of effort, especially if it’s a tool you enjoy in order to get that curated set of stuff. This is my stuff. There’s a whole internet versus full of stuff, but here’s stuff that I’m gonna say is mine.
00:54:05 - Speaker 1: Yeah, we’ve definitely benefited from this whole knowledge management or second brain movement. Uh, those weren’t really in effect back when instant paper and pocket were around, so another framing of reader is kind of a read it later app for that community, which is exactly what you’re talking about, this desire to kind of create your own library and anti-library that’s bespoke to you in the digital realm, not just the physical realm.
00:54:32 - Speaker 3: Yeah, I will also say from the technical side, we did make some decisions that kind of reflect that. So, just if you’re, you know, building a table, say, you know, you have an external web page, and then you have a user, and then you have the fact that this user saved this web page, and so maybe you represent that as like a user save model or something, would maybe be the traditional way you do that, and that’s super normalized, that’s super efficient. We didn’t actually really do that, and maybe Dan can get into more why we did this. It’s more of like a product philosophical thing, but we have this model that we just call the document. And everything you save to reader becomes your own document, so it has its own title, its own author, its own URL, its own metadata, it’s own reading progress, all this stuff. So when you save an external web page, we do have like a cloud representation of, say, uh, Ink & Switch blog post. We have the cloud version of that and we say. You know, 10 users have saved that version, but then each of those users gets their own document of that external URL, and of course the document points at the cloud version in our database, but each user gets their own version of that document, which they can then change, they can change the author, they can change the title, they can add highlights to, they can make progress on. It’s largely a product. Decision is largely led by product decisions, but it’s also just a little bit of a denormalized database solution and it’s actually served us quite well, because now we basically allow users to modify those documents however they want. They can go and edit the author title, they can change the reading position. The client is actually agnostic or the server is agnostic. The client can say they want to change any field on this document, it’s just possible. The user is just updating their own version of that document. Now, of course, there’s some complexity there because You have 2 copies. What if the cloud version actually changes? And what if you make an update to your ink and Switch blog post? Like how does that propagate down to the 1000 people who read that blog post? Do you have to go and update all thousands of those documents? Like, yeah, you do, but the benefits there of users having a document which really is their own, which kind of goes back to the emotional feeling you mentioned Adam, of really saving something and it becoming your own, is very different compared to what a Twitter bookmark is, which is for sure just, you know, two foreign keys, one to the user and one to the Twitter post.
00:56:47 - Speaker 2: Philosophically, this brings to mind commonplace books and marginalia, what people did with their physical books, where precisely as you say, when I buy a physical book, I can rip out the pages, scribble on them, highlight things, and that’s my version of it actually, you know, sometimes the marked up books of famous authors or whatever can go for a lot of money at auction because it represents how they related to the work and their experience of learning from that and their reading experience. But everyone understands that just because I’m scribbling in the book isn’t in any way an attempt to change the source material. This is just my copy of it. To me, that feels just kind of natural and right.
00:57:30 - Speaker 3: Definitely, that’s a great analogy. We think about commonplace books a lot too, but yeah, the document is like actually this core abstraction, probably the core abstraction we have in Reader.
Sometimes we get compared to these like new age of note taking apps, so notion or Rome research or obsidian. You know, a lot of people will ask like, hey, we have these really powerful writing tools. Why can’t I just dump everything I want to read into these note taking apps and just read the content there, and, you know, uh highlight them there, like, you could kind of imagine your own commonplace book in these kinds of apps too, but anyone who’s actually tried this will tell you it doesn’t really work.
It’s hard to exactly say why, you know, not he gives are a little too fluid for the practice of reading.
So, you know, when we were deciding how to build reader, we were like, well, we could build reader block based just like notion where, you know, say every paragraph in an article you’re reading is like its own block and a document is a parent. Block or like an article as a parent block or something, but instead we chose to go with the document and and Dan and I went back and forth on this decision for a long time before deciding it.
Dan is the more prolific writer than me, so maybe he can explain why it’s so motivating from a product perspective, not even a technical perspective.
00:58:40 - Speaker 1: Yeah, when we were starting work on Reader, when we were thinking about it, this was back in 2020 when there was a lot of enthusiasm around this new personal knowledge management evolution, and there were a lot of people who are like, oh, I’m going to do everything in Rome research or notion, like this is the new internet.
So we were definitely wondering like, oh, is the block-based architecture foundational here for us, but like Tristan mentioned, we went back and forth and Kind of got kind of philosophical about it and where we settled was that the abstraction of a block would not be the right abstraction for us as a reading tool, in contrast to a writing tool.
And where we started there was first with the observation that writing and reading, and when I use reading here, I’m referring to reading for betterment, are two sides of the same coin. And really what that is is the writer is transferring knowledge to the reader’s mind. And the medium of transfer is through this abstraction we call a document. And if you actually look at the Latin etymology of document, it means to show, teach, cause to know.
And there are some fundamental differences between a document and a block in terms of abstractions.
I don’t know, have you ever tried to read someone’s wiki link or outliner based page of notes that isn’t your own? It’s very difficult. So I, the first difference is these notes or these blocks, they’re really internally focused, whereas a document is externally focused, a document is written with another person in mind. And then the other difference is that document is the coherent object, it’s held together by connectors, whereas a blocks might just kind of go from one block to another, but the effort hasn’t been made to connect those or link them. And so we started there, and we kind of came up with this idea that reading and writing are creative destruction. Writing is the creation point. You take blocks and you turn them into documents, and then reading, again, reading for betterment is destructive. You’re taking this whole object of a document and then decomposing it into blocks that you can then use for some other purpose, and that’s served us pretty well.
01:00:53 - Speaker 3: Yeah, another approach we could have done is like had different conceptual models for PDF versus book versus article versus newsletter.
Instead, we treat these all as documents, of course, they have different types, so one is type PDF, one is type article, one is type Twitter thread, but at the core they all will mostly have the same metadata fields, they all try to have a title and author, and, you know, some will have an external URL.
All of them will have reading progress. We try to basically give them all a clean reading view of clean HTML. There’s a lot more similarities there than there are differences. Luckily, of course, when you get into PDFs, you obviously have to render those in their own way. YouTube videos the same, but even those have their own clean text layers that the user can highlight, even those have both titles and authors, etc. and so by abstracting away the differences between these documents. We don’t have to build archiving 5 times for 5 different documents. We don’t have to build reading progress, updating logic, and Rendering logic inside of a list, and filtering 5 different types or 5 different document types instead, you know, they all these shared fields, of course some are empty, but it’s made building the product. Of course there are a lot of technical challenges to building an all in one app where you support all these different content types, but at least, you know, the user can feel confident knowing that all of these are documents that they can perform basically all the same actions on. And it gives the product kind of like a pretty comfortable feeling, you know, once you’ve dealt with an article, you can also deal with a book. There’s again a lot of challenges there, and, you know, maybe a book should be treated slightly differently, but, you know, maybe it’s not the fact that it’s a book that means it should be treated differently, you know, maybe it’s the fact that it’s 8 hours long to read, and maybe you want to treat an 8 hour long article the exact same way as you treat a book. That’s kind of what we’re betting on, and that all these different content types really have a lot more similarities than differences.
01:02:45 - Speaker 2: Well, a place to end. I’d love to hear about the longer term ambitions, both for the ReadWise 1.0, the Read later app, and in general where you want to take this business over the coming half decade, decade in the context of your mission about reading for betterment and building software tools that enable people in that.
01:03:07 - Speaker 1: Yeah, in the short term, we’re definitely in this what we call intermediate awkward phase where we’re perceived as having two products, which we lovingly call Readise 1.0 and Reader. We’re actively working now on unifying them. I’m sure you’ve read that famous Joel Spoolsky article, Things You Should Never Do Part one, which is rewrite an existing piece of software.
So we didn’t want to start Reader by rewriting Readwise 1.0, but now we’re in the process of Adding that functionality to reader and making them one unified product, so.
Our hope before the end of the year is that Read Wi will collectively refer to both reader and Readwise 1.0.
But in the longer term, I’ll answer first and then I think Tristan might have a different take, but our hope, you know, in 5 years is that we’ve created a new category of software.
You’ve got this notion of a word processor, no one would ever write a blog post or a book by hand or on a typewriter in 2023. Yeah, reading still pretty much takes place in the physical world, at least nonfiction, 90% of nonfiction reading is still paper books, and so our lofty ambition would be. We’ve created such a better reading experience using software that people are motivated to switch and read digitally.
01:04:26 - Speaker 3: Yeah, this is what Dan was saying, but it goes back to our mission that Dan I started with a little over 6 years ago, which is we want to improve the practice of reading for betterment by an order of magnitude.
And you know, what’s kind of encouraging is users do tell us that we do this for them. It’s definitely not everyone, it’s not even everyone who subscribes to Reader, but there is a significant chunk of these power readers who read a lot, who tell us that we have actually transformed the way they read.
There are a lot of people who tell us, as Dan was saying, they previously read. Uh, mostly on paper or half on paper, and now they’ve switched entirely digital just because Readwise and reader make reading so much better for them.
But again, that is a very small narrow group of people, and, you know, our aspirations over the next half decade is to expand that group, we started. With probably the most demanding readers possible, and we want to expand that group to, you know, more normal folks who, of course, are still reading for betterment, they still want to better themselves through reading, and we think if we can bring these tools to a broader and broader group of people, we’ll feel like we’ve done our job pretty well.
01:05:29 - Speaker 2: Well, it’s wrap it there. Thanks everyone for listening. Join us in Discord to discuss this episode with me and our community. The link will be in the show notes. And Dan Tristan, thanks for pushing us all to read more for betterment.
01:05:41 - Speaker 1: Yeah, thank you for having us and thank you for everything you do.
01:05:45 - Speaker 3: Yeah, thank you so much. It’s been awesome.
