Accidentally Building A Business With Python At Listen Notes

WEBVTT
NOTE
Transcription provided by Podhome.fm
Created: 7/6/2024 5:22:50 PM
Duration: 2608.709
Channels: 1
1
00:00:13.504 --> 00:00:18.244
Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.
2
00:00:18.880 --> 00:00:25.699
When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode.
3
00:00:26.525 --> 00:00:34.465
With the launch of their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform,
4
00:00:34.830 --> 00:00:37.010
including simple pricing, node balancers,
5
00:00:37.310 --> 00:00:38.450
40 gigabit networking,
6
00:00:38.989 --> 00:00:42.770
dedicated CPU and GPU instances, and worldwide data centers.
7
00:00:43.454 --> 00:00:44.754
Go to python podcast.com/linode,
8
00:00:46.414 --> 00:00:56.340
that's l I n o d e, today and get a $100 credit to try out a Kubernetes cluster of your own. And don't forget to thank them for their continued support of this show.
9
00:00:56.879 --> 00:01:04.685
Your host as usual is Tobias Macy. And today, I'm interviewing Wenbin Fang about the technology powering the Listen Notes podcast discovery platform.
10
00:01:04.985 --> 00:01:07.245
So, Wenbin, can you start by introducing yourself?
11
00:01:07.705 --> 00:01:16.210
Sure. First, thanks for having me on. Hello, everyone. I'm Wundhian Feng, founder of Listen Knowles, protocol search engine and database.
12
00:01:16.910 --> 00:01:24.865
I grew up in China, came to the United States in 2010 for graduate study in computer science. Now, I live in San Francisco,
13
00:01:25.405 --> 00:01:26.465
running in ListenKnowles.
14
00:01:27.170 --> 00:01:31.910
Listeners is not a conventional company. It's only 1 full time
15
00:01:32.290 --> 00:01:35.110
employee, just me. I have a few freelancers
16
00:01:35.475 --> 00:01:36.295
helping me
17
00:01:36.675 --> 00:01:38.055
on on and off for
18
00:01:38.355 --> 00:01:43.575
content designs and other stuff. Yeah. And do you remember how you first got introduced to Python?
19
00:01:43.930 --> 00:01:46.270
It was in the summer of 2012
20
00:01:46.890 --> 00:01:48.509
when I was in graduate school.
21
00:01:48.969 --> 00:01:54.905
I was working on a research project. I needed to pass a bunch of log files and do data visualization
22
00:01:55.205 --> 00:01:56.505
using graph v's.
23
00:01:56.965 --> 00:01:59.625
I wanted to use a scripting language,
24
00:02:00.000 --> 00:02:04.340
but I don't remember why I pick Python. Maybe I had the impression
25
00:02:04.640 --> 00:02:06.420
that Python is good
26
00:02:07.395 --> 00:02:10.775
processing strings, textual data, something like that.
27
00:02:11.155 --> 00:02:12.215
Then in 2013,
28
00:02:12.995 --> 00:02:15.415
I joined a startup called Nextdoor,
29
00:02:16.230 --> 00:02:17.610
a local social network.
30
00:02:18.069 --> 00:02:21.930
That's when I joined Django and seriously used Python
31
00:02:22.230 --> 00:02:22.970
to write
32
00:02:23.590 --> 00:02:24.569
production code.
33
00:02:25.004 --> 00:02:37.000
And so can you describe a bit more about what the Listen Notes project is and some of the story behind how it got started and why you decided that this what you wanted to spend your time doing, and how you turned it into a full time business?
34
00:02:37.540 --> 00:02:41.400
So Listenos is a protocol search engine and database. Specifically,
35
00:02:42.245 --> 00:02:43.225
it's 1 database,
36
00:02:43.845 --> 00:02:44.665
3 UIs.
37
00:02:45.045 --> 00:02:47.705
1 Polycom database, 3 user interfaces.
38
00:02:48.325 --> 00:02:57.840
What do I mean? So 1 Polycom database is easy to understand, but we need UIs to access to the database. Right? The first UI is listenos.com.
39
00:02:58.835 --> 00:03:03.015
It's a website. You type in keywords, and then you find Polycast episodes and,
40
00:03:03.555 --> 00:03:04.055
Polycast.
41
00:03:04.595 --> 00:03:07.760
The second UI is the Polycast API.
42
00:03:08.060 --> 00:03:10.720
API stands for application programming interface.
43
00:03:11.180 --> 00:03:13.120
It's a UI. So people,
44
00:03:13.420 --> 00:03:16.615
developers can use the API to build apps, to build
45
00:03:17.075 --> 00:03:17.575
services,
46
00:03:17.875 --> 00:03:20.295
accessing to database and search engine.
47
00:03:20.595 --> 00:03:21.655
Now so the UI,
48
00:03:21.955 --> 00:03:27.240
there's no good name for you, so I call it bring your own UI. So people can come to our website,
49
00:03:27.540 --> 00:03:36.545
export Polycoms metadata into CSV files, and then open in Excel, Google Sheets, or whatever UI. You can write a Python script
50
00:03:36.845 --> 00:03:38.065
to pass the CSV,
51
00:03:38.365 --> 00:03:39.505
bring your own UI.
52
00:03:40.285 --> 00:03:41.265
For stories,
53
00:03:41.805 --> 00:03:49.390
like many software engineers, I've been working on some side projects on and off. Nissanos was 1 of my side projects.
54
00:03:50.010 --> 00:03:52.405
It was started in January
55
00:03:52.705 --> 00:03:53.205
2017.
56
00:03:53.905 --> 00:03:54.405
So
57
00:03:54.705 --> 00:03:57.685
4 years ago, close to 5 5 years ago.
58
00:03:58.319 --> 00:04:03.780
Initially, I worked on this project part time for 1 week, and then launched it.
59
00:04:04.239 --> 00:04:06.659
It was basically a single page,
60
00:04:07.695 --> 00:04:11.395
Then I started to work on it full time in September 2017,
61
00:04:12.415 --> 00:04:16.195
so it's 9 months after I started it as a side project.
62
00:04:16.580 --> 00:04:19.160
Why did I start a side project in the first place?
63
00:04:19.460 --> 00:04:20.280
So, personally,
64
00:04:20.900 --> 00:04:34.389
I really wanted this project to exist. I listened to a lot of podcasts in my spare time, and when I was doing some boring engineering work, like writing unit text, Back in 2016 and 2017,
65
00:04:35.490 --> 00:04:37.590
almost all the Polycast apps
66
00:04:37.970 --> 00:04:43.375
require you to subscribe to Polycast first, and then listen to individual episodes.
67
00:04:43.915 --> 00:04:49.775
This is pretty bad. There are more and more Polycast. I cannot subscribe to too many Polycast.
68
00:04:50.879 --> 00:04:53.060
Actually, I'm an inbox 0 person.
69
00:04:54.080 --> 00:04:56.419
What I really wanted was to be able to
70
00:04:57.039 --> 00:05:01.465
find individual episodes to listen without subscribing to podcast.
71
00:05:02.085 --> 00:05:07.785
Right now, we have listen notes, and today, I use listen notes a lot. I use listen notes to find individual episodes,
72
00:05:08.500 --> 00:05:10.040
add episodes to my
73
00:05:10.580 --> 00:05:15.720
listen data playlist on listen notes dot com, which provides a RSS feed.
74
00:05:16.215 --> 00:05:17.914
I subscribe to this RSSP
75
00:05:18.455 --> 00:05:20.875
overcast. I don't subscribe to any
76
00:05:21.254 --> 00:05:21.754
podcast
77
00:05:22.134 --> 00:05:23.435
other than this RSSP.
78
00:05:24.150 --> 00:05:25.530
Since the end of 2017,
79
00:05:26.630 --> 00:05:29.370
I've listened to more than 5,000 podcast episodes
80
00:05:29.750 --> 00:05:30.630
in this single
81
00:05:31.255 --> 00:05:33.035
Yeah. There are definitely a lot of interesting
82
00:05:33.655 --> 00:05:48.685
usage patterns around podcasts, and I know that there are still a wide number of people who have yet to actually dig into that ecosystem and start exploring the content that's available just because there are a number of kind of user experience quirks to the whole ecosystem
83
00:05:49.064 --> 00:05:56.284
around how you find them, how you consume them. As you were mentioning about, you don't necessarily want to subscribe to the whole show. You just care about 1 episode.
84
00:05:56.970 --> 00:06:07.455
And 1 of the things that I'm interested in digging into a little bit is your point about being able to generate your own custom RSS feed of all the episodes that you care about that you can then subscribe to.
85
00:06:07.915 --> 00:06:17.650
And I know that there are feed aggregator services that are generally used by podcast producers so that if they have multiple different shows, they can have 1
86
00:06:18.190 --> 00:06:21.570
unified RSS feed across all of them. But this is an interesting
87
00:06:22.110 --> 00:06:29.475
sort of different take on it where people can curate their own RSS feed for individual episodes. And I'm wondering if you can maybe dig into some of
88
00:06:29.855 --> 00:06:35.930
the user experience aspects of how that improves the dynamics around being able to consume podcasts
89
00:06:36.550 --> 00:06:48.045
and why people might want to use this capability in listen notes versus just a feed aggregator, like like FeedBurner or something like that? I'm not familiar with feed burner. I can only speak for this and data
90
00:06:48.425 --> 00:06:55.250
playlist on listen notes. I can tell you, some use cases, how people use listen notes and the playlist feature.
91
00:06:55.870 --> 00:07:02.290
So 1 use case is in schools. So teachers who queue the playlist by topic and give the playlist to students,
92
00:07:02.895 --> 00:07:04.914
Use, our listen data feature.
93
00:07:05.215 --> 00:07:05.715
So
94
00:07:06.175 --> 00:07:09.955
we we know that in schools, teachers will cure reading list
95
00:07:10.300 --> 00:07:11.680
for books, for articles,
96
00:07:12.060 --> 00:07:14.960
and with the playlist feature, they can aggregate
97
00:07:15.260 --> 00:07:16.560
episodes by topic.
98
00:07:17.500 --> 00:07:24.475
Also, some email newsletter writers will use listen notes to find episodes and curate podcast episodes.
99
00:07:25.175 --> 00:07:29.035
Because nowadays, many email newsletters are curate content curation
100
00:07:29.660 --> 00:07:31.920
type newsletters. They curate articles,
101
00:07:32.300 --> 00:07:33.680
curate podcast episodes.
102
00:07:34.300 --> 00:07:38.720
Also, some marketing people will need to do content research
103
00:07:39.335 --> 00:07:41.595
across different types of media.
104
00:07:42.135 --> 00:07:45.595
They may want to write a blog post, so they need to do research.
105
00:07:45.975 --> 00:07:48.075
We provide a tool for them to
106
00:07:48.840 --> 00:07:54.780
search Polycast API source by topic, and they can cure rates. And this is very good for content research.
107
00:07:56.405 --> 00:07:59.384
And it could also be, useful for podcasters,
108
00:08:00.165 --> 00:08:05.629
like you. So before interviewing a person, you might want to find a past podcast interviews
109
00:08:06.009 --> 00:08:12.110
for that person, and then binge you this and a little bit to avoid asking the same questions.
110
00:08:13.965 --> 00:08:35.075
Yeah. It's I listen to a number of podcasts myself as well, and so it's always interesting when I have somebody who's scheduled to be coming up on an interview for 1 of my shows, and then I happen to chance across an episode that they did on a different podcast. Like you said, it gives you some ideas about things that you might want to dig into deeper that, you know, were maybe touched on at a surface level in the other podcast.
111
00:08:35.695 --> 00:09:07.585
So I think particularly given the fact that the ubiquitous interface to the Internet as a whole has become search engines, it makes sense that a search engine is the natural interface people are going to gravitate towards as they're first starting to explore the space around podcasts. And I'm wondering if you can talk to some of the kind of discovery capabilities that are present in some of the different podcast applications. So I'm most familiar with Pocket Cast because that's the 1 that I use, but I know that pretty much every system has some level of discovery capability and some of the ways that that surfaces
112
00:09:08.285 --> 00:09:12.440
shows or episodes versus how people experience it when they're coming to listen notes?
113
00:09:12.980 --> 00:09:18.440
When I started listen notes, most podcast apps provide some kind of search ability,
114
00:09:18.805 --> 00:09:21.625
but it mostly only allow you to search podcast,
115
00:09:22.165 --> 00:09:22.904
no episodes.
116
00:09:23.365 --> 00:09:27.065
And what we really wanted, was to search individual episodes.
117
00:09:28.920 --> 00:09:34.300
Today, I see many Polycast apps already provide the episode search.
118
00:09:34.760 --> 00:09:36.700
Their question is whether the search
119
00:09:37.240 --> 00:09:38.395
quality is good
120
00:09:39.595 --> 00:09:43.375
You can also index a bunch of web pages to provide a search engine,
121
00:09:43.915 --> 00:09:47.135
but the key is to provide good search ranking algorithm
122
00:09:47.790 --> 00:09:50.130
to service the most relevant contents.
123
00:09:51.230 --> 00:09:57.165
And this is what we are working on right now to keep improving the search relevance on our search
124
00:09:57.545 --> 00:10:02.845
engine. There are some other discovery features on our website that I don't
125
00:10:03.550 --> 00:10:09.490
see on other podcast apps. For example, there's a feature on website, it's called
126
00:10:10.190 --> 00:10:15.655
listen real time, which is like Google Analytics, real time. You can see
127
00:10:16.035 --> 00:10:19.895
Polycast episodes are being listened right now on our website.
128
00:10:20.730 --> 00:10:23.310
So this is 1 way for people to discover
129
00:10:23.770 --> 00:10:27.470
some niche podcast episodes. They don't even know it is.
130
00:10:28.490 --> 00:10:28.990
Also,
131
00:10:30.765 --> 00:10:34.865
there are a bunch of apps provide some kind of curated list
132
00:10:35.245 --> 00:10:36.625
by human editors.
133
00:10:37.040 --> 00:11:13.010
We also have such a list as well on our website. And as far as being able to actually build a search engine around podcasts, what are the different sources of information that are available for being able to extract some of the useful information that you might be looking for as a consumer of podcasts where I can see who's on the episode, who created the show, what are the topics, you know, being able to dig into the actual content of the episode given that it's generally going to be audio and transcripts are only going to be sporadically available, and just some of the technical kind of data collection aspects of being able to build up the search database?
134
00:11:13.710 --> 00:11:15.250
Primarily, we index
135
00:11:15.550 --> 00:11:17.170
metadata from RSVP,
136
00:11:17.550 --> 00:11:18.930
like title, description,
137
00:11:19.470 --> 00:11:22.555
things like that. If an episode has transcript,
138
00:11:23.175 --> 00:11:26.875
we will also index transcript. Yeah. Banking algorithm,
139
00:11:27.175 --> 00:11:29.435
we actually aggregate multiple signals
140
00:11:29.990 --> 00:11:34.730
to determine what aerosols or protocols to service on top of the results.
141
00:11:35.110 --> 00:11:41.455
So some signals we use, well, I can only disclose a little bit. I don't want to fully disclose everything.
142
00:11:41.835 --> 00:11:42.335
So,
143
00:11:42.715 --> 00:11:45.855
for example, a podcast is mentioned on New York Times,
144
00:11:46.270 --> 00:11:48.050
top 10 true crime podcasts
145
00:11:48.670 --> 00:11:52.450
in a New York Times article, then probably this is a good podcast.
146
00:11:52.910 --> 00:11:59.964
Right? And if an episode is mentioned in the good email news data, then probably this is a good
147
00:12:00.345 --> 00:12:00.845
episode.
148
00:12:01.305 --> 00:12:04.709
So something like that. And we also look at first party data.
149
00:12:05.329 --> 00:12:08.470
So by first party data, I mean, some activities,
150
00:12:09.329 --> 00:12:15.085
from our users, from our website. Like, if an episode is added to a bunch of playlist,
151
00:12:15.945 --> 00:12:20.019
then probably it's it's very popular. It's good. As far as
152
00:12:20.560 --> 00:12:39.600
the product journey of Listen notes, I guess, what were the initial capabilities that you focused on at launch to say these are the most important things that I care about and that I think my users are going to care about and some of the ways that the additional capabilities and features kind of followed on as a natural progression from those initial feature sets?
153
00:12:40.140 --> 00:12:43.680
Yes. So at the very beginning in January 2017,
154
00:12:44.060 --> 00:12:45.964
as I said, it was a single
155
00:12:46.425 --> 00:12:52.605
page web app. So a search bar, you type in keyword, and you see some search results on a single page.
156
00:12:53.120 --> 00:12:58.820
And then after I started working on it full time, I added the playlist feature.
157
00:12:59.279 --> 00:13:03.204
So you can add the individual episodes into Playtest.
158
00:13:04.144 --> 00:13:06.404
And then in the end of 2017,
159
00:13:07.665 --> 00:13:11.605
some people reach out to me asking if we provide API,
160
00:13:12.000 --> 00:13:15.860
because they wanted to add a search feature to their own Polycast app,
161
00:13:16.320 --> 00:13:20.660
so we provide API. And the initial version of API was also simple.
162
00:13:21.105 --> 00:13:23.125
There were only 3 endpoints,
163
00:13:23.665 --> 00:13:24.165
search,
164
00:13:24.545 --> 00:13:27.605
fetch Polycast metadata, and fetch episode metadata,
165
00:13:28.040 --> 00:13:28.780
3 endpoints.
166
00:13:29.640 --> 00:13:30.540
And then later,
167
00:13:31.640 --> 00:13:37.740
we keep providing more Polycast discovery features, like the 1 I mentioned earlier, the real time feature.
168
00:13:38.825 --> 00:13:39.725
And also,
169
00:13:40.265 --> 00:13:44.285
yeah, there are a bunch of discovery features. I don't think I want to enumerate
170
00:13:44.665 --> 00:13:47.175
on my 1, even predicting in the journals.
171
00:13:47.570 --> 00:13:50.310
Pretty much in the past 3 or 4 years
172
00:13:51.170 --> 00:13:54.230
is to iterate on existing features,
173
00:13:54.610 --> 00:13:56.230
mainly incremental improvements.
174
00:13:56.715 --> 00:13:58.415
Right now, if you look at our
175
00:13:58.875 --> 00:13:59.855
product as API
176
00:14:00.475 --> 00:14:00.975
documentation,
177
00:14:01.755 --> 00:14:03.535
you can see a bunch of endpoints.
178
00:14:04.155 --> 00:14:09.170
Pretty much these endpoints mirror to the existing product features on the website.
179
00:14:09.630 --> 00:14:19.125
Digging into the technical implementation and the architecture of the Listen Notes platform, I'm wondering if you can talk through how you designed the system and some of the
180
00:14:19.585 --> 00:14:26.190
technical complexities that have built up as you started to add more capabilities and as you started to
181
00:14:26.570 --> 00:14:29.550
scale out to be able to service your growing customer base?
182
00:14:29.930 --> 00:14:36.714
So I can describe what the architecture looked like right now and then compare it with the initial architecture.
183
00:14:37.175 --> 00:14:37.675
So
184
00:14:38.615 --> 00:14:39.515
as of today,
185
00:14:40.029 --> 00:14:44.850
I primarily describe the decentralized website. Although we have 2 experimental
186
00:14:45.150 --> 00:14:47.810
iOS app, but it's irrelevant. It's irrelevant
187
00:14:48.190 --> 00:14:49.330
to the core product.
188
00:14:49.665 --> 00:14:54.965
So this and those website, the front end is the JS plus Tailwind CSS.
189
00:14:55.745 --> 00:14:58.885
Those JS and the CSS files are bundled
190
00:14:59.270 --> 00:15:00.010
through webpack.
191
00:15:00.710 --> 00:15:04.890
We upload bundles to s 3 and serve through CloudFront.
192
00:15:05.430 --> 00:15:07.745
And for back end, it's primarily
193
00:15:08.125 --> 00:15:14.625
Django and Python for web servers and API servers. And we use Postgres as the main database.
194
00:15:15.350 --> 00:15:22.730
We are running 3 database instances, dv1, dv2, dv3. Dv1 is the master DB, and the other 2 are slave DVs.
195
00:15:23.030 --> 00:15:24.090
We use Elasticsearch
196
00:15:24.745 --> 00:15:28.125
for search engine. There are 3 Elasticsearch instances,
197
00:15:28.745 --> 00:15:29.805
and we use Radius,
198
00:15:30.265 --> 00:15:38.860
obviously, for some caching statistics stuff. We use rapid mq for mister q and the salary for async task workup.
199
00:15:39.240 --> 00:15:40.300
We run everything,
200
00:15:40.825 --> 00:15:43.245
everything, the infrastructure on AWS.
201
00:15:44.105 --> 00:15:46.605
As we are speaking today, December 7,
202
00:15:47.065 --> 00:15:47.565
2021,
203
00:15:48.460 --> 00:15:51.760
AWS is a huge outage right now. At this moment,
204
00:15:52.300 --> 00:15:54.320
US is 1 region is down.
205
00:15:54.700 --> 00:15:54.940
So
206
00:15:55.595 --> 00:16:02.415
okay. So this is the raw architecture for this analysis today. And when I started in January 2017,
207
00:16:03.835 --> 00:16:04.335
the
208
00:16:04.830 --> 00:16:08.210
software I used was roughly the same, with HLS,
209
00:16:08.590 --> 00:16:10.690
Django, Python, Postgres, Elasticsearch,
210
00:16:11.950 --> 00:16:17.015
These are all the same. Except that at the beginning, I were using Footstrap CSS,
211
00:16:17.875 --> 00:16:18.375
and
212
00:16:18.835 --> 00:16:20.535
I ran the whole infrastructure
213
00:16:20.915 --> 00:16:21.735
on 3
214
00:16:22.870 --> 00:16:24.649
small instances on DigitalOcean.
215
00:16:25.190 --> 00:16:26.970
Each instance was like
216
00:16:27.270 --> 00:16:29.370
$10 per month, something like that.
217
00:16:29.915 --> 00:16:33.695
And later on, we migrated from digitals into database.
218
00:16:34.315 --> 00:16:39.500
In terms of scaling up, I think this architecture is very common, and it's very easy to scale up.
219
00:16:40.300 --> 00:16:43.280
Right now, we have several API servers, several
220
00:16:43.660 --> 00:16:47.360
web servers, and we can horizontally scale them up easily.
221
00:16:47.865 --> 00:16:56.590
It seems that probably the most challenging feature to be able to support in a scalable fashion is the real time listening to see what are people
222
00:17:01.310 --> 00:17:01.810
architectural
223
00:17:02.270 --> 00:17:14.640
capabilities that you've built in to be able to support that more near real time feed of information as people are interacting with the website, being able to propagate that back out? We write all these states, these logs to radius,
224
00:17:15.179 --> 00:17:20.160
and is powerful enough to support scale we have right now.
225
00:17:21.395 --> 00:17:22.935
So there's no worry about it.
226
00:17:23.315 --> 00:17:24.695
As far as the
227
00:17:25.395 --> 00:17:35.040
technical choice, I know you mentioned that you learned Python and Django as you were building it next door. And so as engineers, we often gravitate to use what we know. But I'm wondering,
228
00:17:35.434 --> 00:17:42.095
as you were building out the initial project and as you have gone through these different iterations of being able to scale and add new capabilities,
229
00:17:42.840 --> 00:17:46.220
What are some of the decision points that you've gone through about
230
00:17:46.600 --> 00:18:01.020
what other technologies to add in or whether to rearchitect and bring in different technological choices and just some of the either pain points that you've run into about the stack that you chose or some of the benefits that you've realized because of how you've designed things?
231
00:18:01.400 --> 00:18:05.420
Basically, I use all the technologies I already knew at the beginning.
232
00:18:06.040 --> 00:18:08.620
I didn't want to spend time to learn new things.
233
00:18:09.054 --> 00:18:09.715
Those technologies
234
00:18:10.095 --> 00:18:17.235
were used in my former employer, Nextdoor. I know it's beta testing. I know this tech stack can support a multi $1,000,000,000
235
00:18:17.774 --> 00:18:20.419
company. This works fine for this and those.
236
00:18:20.880 --> 00:18:23.139
Yeah. The whole tech stack is pretty similar
237
00:18:23.679 --> 00:18:28.304
to Nextdoor's tech stack. You want to say anything new from Nextdoor?
238
00:18:28.924 --> 00:18:30.385
I think I use Tailwind
239
00:18:30.845 --> 00:18:31.345
CSS,
240
00:18:31.965 --> 00:18:34.065
but it is not part of the
241
00:18:34.610 --> 00:18:49.765
business front end. I don't know if Nextdoor is using Tailwind because it's quite new. Yeah. Banking infrastructure is not really the same. So there's no innovation here, to be frank. Yeah. Well, there's definitely a lot to be said for choosing boring, battle tested technologies
242
00:18:50.145 --> 00:18:55.110
and not innovating on the pieces of the business that don't actually matter to end users. Yeah.
243
00:18:56.130 --> 00:18:58.630
In terms of the podcast ecosystem,
244
00:18:59.090 --> 00:19:02.950
I know that there has been a lot of evolution in terms of some of the
245
00:19:03.345 --> 00:19:03.845
specifications
246
00:19:04.145 --> 00:19:05.445
for RSS formats
247
00:19:06.385 --> 00:19:10.405
and new entrants as far as companies who are offering podcasts in their
248
00:19:10.710 --> 00:19:18.650
different platforms, most notably, Spotify and Amazon Music have been some of the recent entrants, but there have also been companies like Pandora
249
00:19:19.110 --> 00:19:19.610
and
250
00:19:20.005 --> 00:19:29.809
number of others that have added capabilities. And there are a bunch of different discovery platforms that have come about for making it easier for end users to find and discover podcasts they care about
251
00:19:30.190 --> 00:19:42.904
or platforms for podcast hosts to be able to network with their listeners. And I'm just wondering what you have seen as some of the most notable changes in the ecosystem surrounding podcasts and particularly in terms of the
252
00:19:43.205 --> 00:19:52.570
feed formats and data sources that have become available for you to be able to incorporate additional signals to people who are trying to find the information that they care about?
253
00:19:52.945 --> 00:19:58.245
I haven't seen much changes in the irisense format. There's some specification
254
00:19:58.705 --> 00:19:59.205
changes,
255
00:19:59.799 --> 00:20:01.020
but it's really hard
256
00:20:01.480 --> 00:20:05.500
to get all the major platforms to adopt the same standard,
257
00:20:05.880 --> 00:20:07.020
especially AirPod.
258
00:20:08.085 --> 00:20:16.670
So how do you talk to Air Force Podcast? How do you find a human being from Air Force Podcast to talk to them, ask them to support
259
00:20:16.970 --> 00:20:18.590
a a specific new specification?
260
00:20:19.290 --> 00:20:23.215
Right? If Apple Podcast doesn't adopt the new specification,
261
00:20:23.995 --> 00:20:24.495
then,
262
00:20:25.435 --> 00:20:26.975
I think it's it's very challenging.
263
00:20:27.275 --> 00:20:27.775
Yeah.
264
00:20:28.315 --> 00:20:39.410
And as far as the types of information, you were mentioning that you were pulling in the RSS feed metadata, looking at hosts and topics and things like that. And I'm wondering if there are any more
265
00:20:39.755 --> 00:20:57.665
sort of analytical processes that you're bringing in to do things like entity resolution or anything like that to give more you know, building out a knowledge graph to make it easier for people to be able to say, okay, I found this person in in this 1 podcast. Now list all the other places that they've shown up. In the back end, we run NLP entity recognition
266
00:20:58.285 --> 00:21:07.350
to extract persons' names, locations, events, things like that. If you go to our web page for individual Polycast episodes, you'll find this kind of information.
267
00:21:07.810 --> 00:21:10.230
When you click a person's name, and you
268
00:21:10.835 --> 00:21:15.575
bring up a list of search results for that specific person, specific location,
269
00:21:15.955 --> 00:21:27.320
yeah, something like that. And then as far as the API aspect of it, you mentioned that when you launched, there were 3 endpoints available, and it was very simple and straightforward. And I'm wondering what you have
270
00:21:27.620 --> 00:21:30.335
settled on as far as any design philosophies
271
00:21:30.794 --> 00:21:40.760
or your overall approach to identifying how to structure that API so that it is useful and composable for end users to be able to build different applications on top of?
272
00:21:41.060 --> 00:21:43.160
It's actually a very natural evolution.
273
00:21:43.755 --> 00:21:44.255
So,
274
00:21:44.635 --> 00:21:47.935
as I said, API was initially launched in the end 2017.
275
00:21:48.875 --> 00:21:51.295
You had the 3 API endpoints initially,
276
00:21:51.659 --> 00:21:53.279
and then it evolves naturally.
277
00:21:53.980 --> 00:21:58.399
So first, I made major website features to the API endpoints.
278
00:21:59.034 --> 00:22:03.695
And I also talk to API users frequently, and their feedbacks are very important
279
00:22:04.154 --> 00:22:15.870
to decide, how the API would look like, what kind of response data, what kind of data fields they need to build an app. 1 principle I stick to is, is always be well compatible.
280
00:22:16.475 --> 00:22:17.294
Don't break
281
00:22:18.075 --> 00:22:19.615
the existing API endpoints.
282
00:22:20.154 --> 00:22:21.534
In terms of the
283
00:22:21.995 --> 00:22:29.290
technical challenges that you faced, what have been some of the most complex or difficult aspects of building the business
284
00:22:29.830 --> 00:22:38.945
and being able to scale to where you are now and being able to sort of collect useful signals and feedback from end users to improve and iterate on the project?
285
00:22:39.405 --> 00:22:42.490
But to be honest, all these technical stuff, all
286
00:22:42.790 --> 00:22:43.770
solved issues,
287
00:22:45.110 --> 00:22:49.130
they are not that difficult. Some of them are quite time consuming.
288
00:22:49.845 --> 00:22:50.904
I'll give you example.
289
00:22:51.445 --> 00:22:53.705
Upgrading Postgres from 9.17
290
00:22:54.565 --> 00:22:57.065
to the version 11 without significant
291
00:22:57.365 --> 00:22:57.865
downtime.
292
00:22:58.450 --> 00:23:01.670
It is easy to say, but it's not easy to do.
293
00:23:02.290 --> 00:23:02.790
So
294
00:23:03.090 --> 00:23:04.070
with the upgrade,
295
00:23:04.530 --> 00:23:05.990
always keep the infrastructure
296
00:23:06.610 --> 00:23:07.110
software
297
00:23:07.525 --> 00:23:10.505
to the latest version. If not the latest version, at least
298
00:23:11.045 --> 00:23:14.505
close to the latest version because of bug fixes, security
299
00:23:14.965 --> 00:23:15.465
fixes,
300
00:23:15.765 --> 00:23:17.060
new features. Right?
301
00:23:17.780 --> 00:23:20.920
It's always a drama, tech companies, for upgrading
302
00:23:21.300 --> 00:23:22.520
across major versions,
303
00:23:22.820 --> 00:23:24.040
especially for database.
304
00:23:24.705 --> 00:23:27.365
Last time, I upgraded the host grades from 9.17
305
00:23:27.905 --> 00:23:30.405
to 11. I managed to achieve
306
00:23:30.945 --> 00:23:33.285
between 30 seconds 60 seconds
307
00:23:33.880 --> 00:23:37.820
downtime for write access and 0 downtime for read access.
308
00:23:38.200 --> 00:23:41.915
So, they involve a lot of prep work and a bunch of rehearsals
309
00:23:42.775 --> 00:23:43.595
on staging
310
00:23:43.895 --> 00:23:44.395
environment.
311
00:23:44.935 --> 00:23:47.915
Just to emulate all kinds of failure scenarios,
312
00:23:48.550 --> 00:23:52.650
and try to recover the service, how to go back, things like that.
313
00:23:53.030 --> 00:23:56.810
This is challenging. We need to do similar thing for Elasticsearch,
314
00:23:57.804 --> 00:24:02.144
other pieces of infrastructure to our software. Right now, we are providing API.
315
00:24:02.445 --> 00:24:03.585
We need to make sure
316
00:24:03.965 --> 00:24:08.440
API doesn't go down, doesn't have 0 time, doesn't have downtime.
317
00:24:08.980 --> 00:24:12.120
So, yeah, it's challenging to manage this kind of infrastructure.
318
00:24:12.820 --> 00:24:17.955
Going back to the entrance of new businesses and interests in the podcast ecosystem.
319
00:24:18.735 --> 00:24:23.875
So Spotify probably had the most amount of press around it because it was such a big player in the music ecosystem already.
320
00:24:24.230 --> 00:24:28.009
And I'm wondering what you've seen as far as some of the shifts in the
321
00:24:28.470 --> 00:24:33.450
ways people are discovering podcasts or getting introduced to the idea of podcasts
322
00:24:33.795 --> 00:24:42.055
as these bigger companies start to play in the ecosystem and how that has influenced the way that you think about the value that you're providing to the space.
323
00:24:42.610 --> 00:24:43.909
So for Spotify's
324
00:24:44.289 --> 00:24:45.510
entrance into Polycast,
325
00:24:46.049 --> 00:24:53.915
I don't think it affects listeners too much because it's a it's a work out that it doesn't participate in the open ecosystem.
326
00:24:54.775 --> 00:24:55.275
Arguably,
327
00:24:55.735 --> 00:25:01.260
people can say, over Spotify is provided, it's not Polycast, because it's not based on ISP,
328
00:25:01.720 --> 00:25:04.140
but based on the narrow definition of ISP.
329
00:25:04.520 --> 00:25:07.020
Right? But, a good thing is, Spotify
330
00:25:07.955 --> 00:25:09.335
expand the audience
331
00:25:09.795 --> 00:25:10.695
audio consumption,
332
00:25:11.395 --> 00:25:12.615
the spoken audios.
333
00:25:12.915 --> 00:25:13.415
Right?
334
00:25:13.795 --> 00:25:14.295
The
335
00:25:15.640 --> 00:25:17.340
podcast listener, Spotify,
336
00:25:17.800 --> 00:25:19.580
might not be the traditional
337
00:25:19.960 --> 00:25:20.620
or existing
338
00:25:21.000 --> 00:25:23.820
podcast listeners. So existing podcast listeners
339
00:25:24.325 --> 00:25:25.065
pretty much
340
00:25:25.445 --> 00:25:26.425
use the same
341
00:25:27.125 --> 00:25:27.625
open
342
00:25:27.925 --> 00:25:30.425
RSS space, the Polycast players.
343
00:25:31.045 --> 00:25:40.020
And Spotify may only target to their existing users, music listeners, and they hand them to discover, oh, there's a spoken audio there.
344
00:25:40.975 --> 00:25:41.475
As
345
00:25:42.015 --> 00:25:47.155
a podcaster myself, 1 of the challenges of the ecosystem is being able to understand
346
00:25:47.535 --> 00:25:48.434
who your audience
347
00:25:56.020 --> 00:25:56.520
reasons
348
00:25:57.635 --> 00:26:06.695
this is how many listeners I have is if you own the whole experience. And I'm wondering what you've seen as some of the useful pieces of information that you're able to provide
349
00:26:07.440 --> 00:26:16.180
either both you know, whether for your own purposes of being able to see what are people's listening habits or being able to provide back to podcast producers
350
00:26:16.635 --> 00:26:29.779
because of the fact that you do have a mechanism for consuming those podcasts and just some of the useful types of information that you're able to generate from listen notes? I would say I haven't done much to provide such a status back
351
00:26:30.080 --> 00:26:31.299
to product house producers,
352
00:26:31.759 --> 00:26:37.015
but in the future, we certainly do more. Right now, we certainly have the search history
353
00:26:37.794 --> 00:26:39.174
for how people
354
00:26:39.635 --> 00:26:41.015
discover certain polycast.
355
00:26:41.475 --> 00:26:43.095
We have the listen history,
356
00:26:43.410 --> 00:26:51.990
listen stays for individual episodes on our own platform. Basically, each podcast players all have their own listen stays
357
00:26:52.435 --> 00:26:53.015
by its fragmented.
358
00:26:54.035 --> 00:27:01.095
We developed a new metric called distance score, which is to estimate the popularity of podcast
359
00:27:01.830 --> 00:27:03.610
and then provide a global ranking.
360
00:27:04.070 --> 00:27:06.330
This is to give people a lot of sense
361
00:27:06.630 --> 00:27:28.825
how popular, especially Polycoms is. It's not 100% accurate. You have a basic sense. Yeah. As I was preparing for this interview, I was looking at my own podcasts on there and was happy to see that they were ranking in the top 1%. So I don't know if you can maybe dig a bit more into some of the signals that you're using to determine that popularity metric and what it actually means to be within a given percentile.
362
00:27:29.365 --> 00:27:35.030
Yeah. So ASR a decent score is used in our search ranking algorithm. So just now, I I mentioned that,
363
00:27:35.410 --> 00:27:38.390
a few signals we use to determine the search ranking.
364
00:27:38.930 --> 00:27:41.270
Azure, we use the same signals to calculate
365
00:27:41.810 --> 00:27:43.155
such a recent score.
366
00:27:43.555 --> 00:27:50.775
Basically, we use the 1st party data and the 3rd party data. 1st party data are the user activities on our own ecosystem,
367
00:27:51.370 --> 00:27:59.390
And so the party datas are those on the open web. I mentioned New York Times say, oh, this is 1 of the top 10 true crime podcast,
368
00:27:59.690 --> 00:28:03.125
something like that. And also some social media activities,
369
00:28:03.425 --> 00:28:07.685
and we combine all these signals together, and there's a formula.
370
00:28:08.269 --> 00:28:11.009
We assign different weights on each signal,
371
00:28:11.309 --> 00:28:12.529
come up with this score.
372
00:28:12.830 --> 00:28:14.769
We still need to continue tweaking
373
00:28:15.070 --> 00:28:16.210
the the score.
374
00:28:16.695 --> 00:28:19.595
And the global ranking is based on these scores.
375
00:28:19.975 --> 00:28:53.555
Yeah. It definitely seems like there's a lot of interesting opportunities for adding additional sort of data processing workflows to be able to bring in some of that additional information. So being able to do things like every time you find a podcast that's registered or that's indexed on your platform, you can maybe set up a Google Trends alert or to say, anytime this podcast is mentioned, I'll get a notification that'll serve as another signal into this to be able to bump it up in the, you know, recommendation algorithm, things like that, or being able to do additional entity extraction if this host appears on this other podcast. So
376
00:28:54.435 --> 00:29:02.535
and then as far as being able to manage all those workflows, are you just doing that as Celery tasks within the web application, or do you also have a dedicated
377
00:29:02.929 --> 00:29:09.429
sort of data infrastructure to be able to pull in these signals and process it and then load it into the database to be able
378
00:29:09.809 --> 00:29:12.295
to have a more pre aggregated view of it?
379
00:29:12.615 --> 00:29:14.475
So we use ClearHouse.
380
00:29:14.855 --> 00:29:24.049
I forgot to mention ClearHouse in the infrastructure part. We use ClearHouse to store some aggregate data logs. It's a column based data warehouse.
381
00:29:24.429 --> 00:29:28.210
Yes. We use Ceri as async task to do the heavy lifting
382
00:29:28.590 --> 00:29:29.409
data crunching.
383
00:29:30.554 --> 00:29:33.775
And also, radius, is also used in in the pipeline.
384
00:29:34.235 --> 00:30:04.750
It's multiple pieces. As with everything in technology, there are so many different ways that you can approach it. So it's always interesting to see the pieces that people put together to solve their different problems. And so given the fact that you have a few different interfaces on top of this overall trove of data, I'm wondering if you can talk to some of the main use cases that people have built out for Listen notes, whether it's end users who are using the web UI to discover and curate a podcast feed or people who are building applications on top of the API or
385
00:30:05.075 --> 00:30:14.775
doing their own data analysis from the CSV exports and just some of the workflows that people are building out around Listen notes as a platform service.
386
00:30:15.220 --> 00:30:19.400
Yeah. I I talked about the use cases for API first. So,
387
00:30:20.020 --> 00:30:20.520
basically,
388
00:30:20.980 --> 00:30:24.040
if you want to access to a Polycast database
389
00:30:24.635 --> 00:30:26.255
or you want to search a Polycast,
390
00:30:26.955 --> 00:30:32.095
you have 2 choices. You build your own search engine, you build your own database, or you use some kind of API.
391
00:30:32.909 --> 00:30:33.970
There are some examples.
392
00:30:34.429 --> 00:30:49.935
So, for example, people want to build their own podcast app. I didn't know that there are so many podcast apps out there. If you search Polycast app in App Store, you can see a bunch of niche Polycast apps. And, also, there are many Polycast clipping apps.
393
00:30:50.550 --> 00:30:51.770
So people
394
00:30:52.070 --> 00:30:53.370
can create clips,
395
00:30:53.830 --> 00:30:56.810
short clips from Polycast ADSource and share to
396
00:30:57.110 --> 00:31:02.774
social media. And then we use our API to search to find specific episode.
397
00:31:03.154 --> 00:31:05.975
Basically, it uses a better way for onboarding users.
398
00:31:06.710 --> 00:31:09.530
Also, a bunch of audio apps
399
00:31:10.150 --> 00:31:12.490
that want to get into Polycast,
400
00:31:12.950 --> 00:31:14.409
they will use our API,
401
00:31:15.225 --> 00:31:17.725
like music apps, audiobook apps.
402
00:31:18.025 --> 00:31:27.280
Spotify is not the only music app in the world. There are tens of thousands of small music apps. And also, Audible is not the only audio app.
403
00:31:27.740 --> 00:31:30.480
There are tons of audio app. And so,
404
00:31:30.780 --> 00:31:34.895
Polycom is a very good adjacent market for them to expand to.
405
00:31:35.435 --> 00:31:42.015
Also, there are some social apps that allow people to share and discuss things, like movies, games,
406
00:31:42.700 --> 00:31:44.160
restaurants, and podcasts.
407
00:31:44.540 --> 00:31:46.800
And we provide a search feature
408
00:31:47.180 --> 00:31:50.880
so their users can easily find podcasts and discuss podcasts.
409
00:31:52.165 --> 00:31:55.145
And also some content curation sites,
410
00:31:56.005 --> 00:32:00.985
our content discovery sites, so we use our API to help people discover podcasts.
411
00:32:01.570 --> 00:32:05.750
1 specific example is some website will provide information for specific
412
00:32:06.610 --> 00:32:07.110
stock.
413
00:32:07.650 --> 00:32:11.095
They will list all the podcast interviews from the CEO
414
00:32:11.475 --> 00:32:12.375
or CFO
415
00:32:12.835 --> 00:32:24.010
from a public company. So people can listen to the Polycast interviews and make decisions, whether or not to buy the stock. Well, this is not a good investment advice, somehow you get a signal.
416
00:32:24.310 --> 00:32:26.730
These are the rough use case of our API.
417
00:32:27.510 --> 00:32:29.530
And in terms of the CSV buyers,
418
00:32:30.505 --> 00:32:32.044
some financial institutions
419
00:32:32.345 --> 00:32:33.404
would want to
420
00:32:33.705 --> 00:32:34.205
find
421
00:32:34.904 --> 00:32:38.125
as much data as possible to do, for some
422
00:32:38.664 --> 00:32:39.485
stock picking,
423
00:32:40.030 --> 00:32:41.490
stock alternative data,
424
00:32:41.870 --> 00:32:42.850
satellite data,
425
00:32:43.150 --> 00:32:44.370
or protocols data.
426
00:32:44.670 --> 00:32:47.170
So they will search a person's name or topic,
427
00:32:47.630 --> 00:32:53.915
something like that. I don't really know, how they use our data. They just export the data, and they will use it.
428
00:32:54.215 --> 00:32:56.555
Also, some PR companies
429
00:32:57.090 --> 00:33:00.630
want to pitch to Polycast for guest opportunities.
430
00:33:01.250 --> 00:33:08.765
So they will need a bunch of Polycast information to do research on what Polycast to pitch to. Yeah. I definitely get lots of those emails.
431
00:33:10.664 --> 00:33:21.389
And so for people who are using Python and want to consume the Listen Notes API, it seems seems that you have an SDK available. I'm wondering if you can talk to some of your motivation for
432
00:33:21.690 --> 00:33:30.425
building out a dedicated client library versus just telling people to just use requests and have at it? So it's interesting. Oh, I forgot to mention 1
433
00:33:31.045 --> 00:33:38.090
important use case, our API. Our API is used in many coding boot camps. I don't think you can use best
434
00:33:38.870 --> 00:33:40.330
new programmers to
435
00:33:40.710 --> 00:33:44.090
use REST API right away. They might need some
436
00:33:44.675 --> 00:33:47.335
specific SDK, language specific SDKs
437
00:33:47.875 --> 00:33:49.335
to make function calls.
438
00:33:49.795 --> 00:33:53.015
So we provide a bunch of SDKs in different languages.
439
00:33:53.860 --> 00:33:55.160
We have Python SDK,
440
00:33:55.700 --> 00:33:56.200
Nubi,
441
00:33:56.580 --> 00:33:57.080
Knowledges,
442
00:33:57.620 --> 00:33:58.120
Lost,
443
00:33:58.660 --> 00:33:59.160
Suite,
444
00:33:59.460 --> 00:33:59.960
Java,
445
00:34:00.580 --> 00:34:01.080
Go,
446
00:34:01.534 --> 00:34:03.794
Basically, all the major languages. Yeah.
447
00:34:04.095 --> 00:34:18.059
What are some of the types of convenience features that you're building into the SDK to make it easier to work with the Listen Notes API and some of the, maybe, common workflows that people are trying to build around it? Actually, nothing exciting now. It's a thin
448
00:34:18.440 --> 00:34:18.940
repo.
449
00:34:21.225 --> 00:34:33.710
And I guess as far as people who are using listen nodes, either as end users or people who are building applications on top of it, what are some of the most interesting or innovative or unexpected ways that you've seen the API used?
450
00:34:34.250 --> 00:34:37.150
A lot of people search promo code
451
00:34:37.545 --> 00:34:38.445
to find deals
452
00:34:38.825 --> 00:34:40.205
using this and those
453
00:34:40.505 --> 00:34:41.005
website
454
00:34:41.305 --> 00:34:42.125
and API.
455
00:34:42.505 --> 00:34:48.780
Actually, there's a company use our API to find promo code because they are providing some coupons
456
00:34:49.160 --> 00:34:50.700
to people. You know,
457
00:34:51.080 --> 00:34:54.540
1 major monetization strategy for Polycast is to
458
00:34:54.915 --> 00:34:56.135
provide promo code.
459
00:34:56.515 --> 00:35:16.615
As the podcast ecosystem continues to evolve and mature and more companies and individuals become involved in it, what are some of the missing pieces that you think can and should be filled in to make it more viable as a broad ecosystem so that more people can interact and collaborate and grow the entire community?
460
00:35:17.155 --> 00:35:22.055
Personally, I really want to have a unique ID of individual
461
00:35:22.355 --> 00:35:22.855
episodes
462
00:35:23.700 --> 00:35:26.359
that major Polycast platforms all agree.
463
00:35:26.980 --> 00:35:27.720
So nowadays,
464
00:35:28.020 --> 00:35:29.160
if you want to
465
00:35:29.619 --> 00:35:30.119
uniquely
466
00:35:30.475 --> 00:35:30.975
identify
467
00:35:31.275 --> 00:35:35.695
a Polycast, you may use ISSP or Apple Polycast ID.
468
00:35:35.995 --> 00:35:37.215
But how about Aviso?
469
00:35:37.700 --> 00:35:38.440
So there's
470
00:35:38.980 --> 00:35:40.599
no unique ID for Aviso
471
00:35:40.900 --> 00:35:41.880
across platform.
472
00:35:42.580 --> 00:35:45.400
So if you want to share Aviso to
473
00:35:45.780 --> 00:35:46.280
Twitter,
474
00:35:46.775 --> 00:35:57.130
okay, or URL do you use? You can always just use Apple Podcast URL, where Android users will be pissed off. If you share Spotify link, well, not everyone
475
00:35:57.510 --> 00:35:58.810
is a Spotify user,
476
00:35:59.270 --> 00:36:03.530
then what URL do you use? Somehow you need to have a unique ID
477
00:36:03.935 --> 00:36:08.995
so you can deep link and then open whatever apps you have on the system. So,
478
00:36:09.295 --> 00:36:11.155
yeah. There's a GUID
479
00:36:11.535 --> 00:36:12.915
tag in RSSP,
480
00:36:13.680 --> 00:36:15.220
but it's not reliable.
481
00:36:16.000 --> 00:36:19.780
The GUID is not permanent. It changes a lot,
482
00:36:20.800 --> 00:36:22.500
so there's no unique ID.
483
00:36:22.915 --> 00:36:31.735
Yeah. I've had to regenerate the GWT on a couple of episodes because of publishing errors. So I'm definitely guilty of being somebody that changes that.
484
00:36:32.515 --> 00:36:33.769
We don't use GUID,
485
00:36:34.309 --> 00:36:37.690
in Nissan Alt. We don't trust it. With good reason.
486
00:36:37.990 --> 00:36:58.888
And then as far as being able to have that kind of universal linking, I know that there are a few different platforms and services that are offering that as a feature where, you know, you publish your RSS feed through us, and then we'll give you a single endpoint that you can share with people so that it will automatically open the appropriate podcast player on their platform of choice. That
487
00:36:59.356 --> 00:37:07.820
that's only for the entire podcast because they uniquely identify podcast by RSVP or iTunes ID. It's not a PC.
488
00:37:08.120 --> 00:37:08.860
Fair point.
489
00:37:09.400 --> 00:37:25.645
And as you have spent a lot of time building the Listen Notes project and digging into the podcast ecosystem, what are some of the most interesting or unexpected things that you've learned about podcasts, the ecosystem around it, and the ways that people are consuming and using podcasts in their daily lives?
490
00:37:26.060 --> 00:37:29.520
I would say that I would be surprised that there's a
491
00:37:29.820 --> 00:37:34.880
I was surprised to learn that there's a podcast for that. Basically, you can learn anything.
492
00:37:35.575 --> 00:37:36.075
Just
493
00:37:36.375 --> 00:37:37.355
listen to Polycast.
494
00:37:37.895 --> 00:37:41.195
Polycast are very good, informal, lending material.
495
00:37:41.655 --> 00:37:52.780
If you want to learn a new topic, you can search, and you can find some experts talking about a topic. It's informal lending because if you want to dig deeper, you still need to read books or attend lectures.
496
00:37:54.585 --> 00:37:57.005
As a consumer of podcasts yourself,
497
00:37:57.305 --> 00:37:58.525
what are some of the
498
00:37:59.305 --> 00:38:07.119
best practices that you've seen from some publishers that you think can and should be more broadly adopted by
499
00:38:07.420 --> 00:38:10.799
everybody who's producing podcasts, whether it's in terms of the
500
00:38:11.235 --> 00:38:17.815
information that they're producing in the RSS feed or things that they're including in the show notes or the availability of transcripts
501
00:38:18.115 --> 00:38:23.980
or just anything having to do with making it more accessible for end users to be able to understand
502
00:38:24.520 --> 00:38:28.220
more easily what it is that they're going to get out of it as a as a listener.
503
00:38:28.674 --> 00:38:30.775
There's 1 thing I wish more podcasts
504
00:38:31.154 --> 00:38:32.615
use, stricter markers.
505
00:38:33.234 --> 00:38:37.734
People can know, oh, this segment is talking about what, which timestamp.
506
00:38:38.310 --> 00:38:39.930
Now there's many Polycast
507
00:38:40.230 --> 00:38:46.984
players support the deep link to specific timestamp, so you clear on timestamp, and then you can fast forward to
508
00:38:47.365 --> 00:38:48.425
a specific location.
509
00:38:48.964 --> 00:38:51.065
Alright. I will take that as feedback,
510
00:38:52.005 --> 00:38:59.600
the way I'm producing my podcast. Thank you. Can't promise anything because it is a bit of a labor intensive process, but I will take note.
511
00:39:00.620 --> 00:39:02.635
And in terms of your own experience
512
00:39:02.955 --> 00:39:11.535
of building the Listen Notes platform and growing it as a business, what are some of the most interesting or unexpected or challenging lessons that you've learned in the process?
513
00:39:12.110 --> 00:39:16.530
2 things. I want to say 2 things. 1 is great customer service
514
00:39:16.910 --> 00:39:19.170
is an effective marketing strategy.
515
00:39:19.685 --> 00:39:26.905
I personally reply emails very fast. I try to be helpful. Some people send emails asking for Polycast recommendations.
516
00:39:27.589 --> 00:39:28.410
I would reply
517
00:39:28.869 --> 00:39:30.250
with with specific Polycast.
518
00:39:30.950 --> 00:39:36.569
So I think if you serve customers well, they will help promote your service, your company.
519
00:39:37.105 --> 00:39:40.565
So providing great customer service is very important.
520
00:39:40.865 --> 00:39:45.365
That's 1 thing. And the second thing is, I'm surprised to find that there are
521
00:39:45.740 --> 00:39:47.839
a bunch of fake podcasts
522
00:39:48.380 --> 00:39:50.160
for link building purposes.
523
00:39:51.020 --> 00:39:53.839
Some player has SEO from India and Pakistan
524
00:39:54.140 --> 00:39:54.960
tried to
525
00:39:55.345 --> 00:39:56.725
submit fake podcasts,
526
00:39:57.345 --> 00:40:02.725
containing synthetic audio and a bunch of things. They tried to link building.
527
00:40:03.500 --> 00:40:08.240
So on our end, we need to build a bunch of tools to fight such, fake podcast.
528
00:40:08.860 --> 00:40:23.520
For people who are looking for a way to discover new podcast or specific episodes, what are some of the cases where Listen notes might be the wrong choice and they're better suited just going with the Spotify app that they're already using or, general Google search?
529
00:40:24.060 --> 00:40:28.000
So we suddenly don't have exclusive contents from Spotify.
530
00:40:28.300 --> 00:40:34.315
It's illegal for us to provide exclusive contents on our platform. So if you want to listen to
531
00:40:34.775 --> 00:40:35.275
Spotify's
532
00:40:35.735 --> 00:40:37.275
exclusives, go to Spotify.
533
00:40:38.295 --> 00:40:39.355
Other than that,
534
00:40:39.735 --> 00:40:41.675
I think business knows it's a good place
535
00:40:42.090 --> 00:40:43.550
to discover the Holocaust.
536
00:40:43.850 --> 00:40:46.430
I certainly have bias. Fair enough. And
537
00:40:47.290 --> 00:40:48.830
as you continue to
538
00:40:49.255 --> 00:40:56.954
manage the platform and build the project and add new features and capabilities, what are some of the things you have planned for the near to medium term?
539
00:40:57.290 --> 00:41:01.230
Instead of giving you very concrete product features or infrastructure
540
00:41:01.530 --> 00:41:02.030
improvement,
541
00:41:02.410 --> 00:41:10.855
Android is something more vague. So, basically, we we want to continue to help people find quality EO time, as opposed to screen time.
542
00:41:11.235 --> 00:41:13.175
So screen time basically means
543
00:41:13.579 --> 00:41:16.720
watch your Netflix, you scroll down, Instagram feed.
544
00:41:17.099 --> 00:41:18.559
Your time is underutilized.
545
00:41:19.339 --> 00:41:22.079
People need to have more quality your time.
546
00:41:22.405 --> 00:41:29.625
Listening to podcast, listening to good podcast, listening to good audio books, things like that. Right now, we focus on podcast,
547
00:41:29.960 --> 00:41:32.779
but maybe in the future, we will expand to other verticals.
548
00:41:33.400 --> 00:41:49.309
Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us into the picks. This week, I'm going to recommend the Wheel of Time series that Amazon recently launched. I will admit that I have not read the books.
549
00:41:49.869 --> 00:42:08.329
It's definitely seems to be quite the undertaking to have done that, but I've started watching the show, and they seem to have done a really good job, at least for somebody who isn't familiar with the books. I thoroughly enjoy it, so definitely recommend that to people who are looking for something to watch. And with that, I'll pass it to you, Wenden. What do you have for a pick this week? I will recommend Superhuman,
550
00:42:08.710 --> 00:42:09.690
the email client.
551
00:42:10.230 --> 00:42:13.050
It's not free. You need to pay $30 per month.
552
00:42:13.605 --> 00:42:16.505
But as a heavy email users,
553
00:42:16.885 --> 00:42:20.905
I think Superhuman saved me a ton of time, so it's worth paying them.
554
00:42:21.260 --> 00:42:22.640
Yeah. I reply emails
555
00:42:23.099 --> 00:42:25.599
a lot. I spend a lot of time with emails.
556
00:42:26.140 --> 00:42:44.180
Alright. Well, thank you very much for taking the time today to join me and share the work that you're doing at Listen Notes and for all of the time and effort you've put into helping make podcasts more discoverable and consumable by more people. Definitely appreciate all the time and energy you put in there, and I hope you enjoy the rest of your day. Thank you again for having me on. It's a great pleasure.
557
00:42:46.720 --> 00:42:52.795
Thank you for listening. Don't forget to check out our other show, the data engineering podcast at data engineering podcast.com
558
00:42:53.335 --> 00:42:55.195
for the latest on modern data management.
559
00:42:55.960 --> 00:42:57.420
And visit the site of pythonpodcast.com
560
00:42:58.520 --> 00:43:01.980
to subscribe to the show, sign up for the mailing list, and read the show notes.
561
00:43:02.280 --> 00:43:07.405
And if you've learned something or tried out a project from the show, then tell us about it. Email host at podcastinit.com
562
00:43:08.105 --> 00:43:08.925
with your story.
563
00:43:09.785 --> 00:43:13.885
To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.