My Stories Startups

Short-form podcasts are the future, just not mine

Long story short, after coronavirus made me come back from the Los Angeles part of my March business trip early and importing was out of the question, I decided to start a podcasting company.

By myself, with my $150 Blue Yeti mic. Not much, but certainly enough to get started – or so I thought.

During the first recording session, I realized there’s one big problem: I sound terrible. Proper intonation and voice acting were more difficult than I expected.

I’ve spent 3 weeks trying to get it to an acceptable level – speaking faster, slower, louder, quieter, with more pauses, with fewer pauses… it just wasn’t there. Not being a native English speaker didn’t help, either.

So eventually there was no podcasting company.

But when figuring things out, I came to something that can be a big trend in the coming years: short-form podcasts.

When writing a script for the first episode that was meant to be about 20 minutes long, I found it pretty time-consuming.

Considering I wanted to start multiple podcasts, releasing at least 1 episode a week for each of them, it wasn’t possible to spend that much time just writing.

The solution proved to be very simple: why not just make the episodes shorter?

Instead of producing 1 20-minute episode, I’d produce 3 7-minute episodes. That meant 3 weeks’ worth of content instead of 1 week’s worth of content.

I needed some rationale to potentially explain why the heck are all podcasts so short. After some research, it started to make even more sense than I expected.

First, Edison Research found out in 2018 that 50% of people not listening to podcasts don’t listen because they’re too long.

Second, the video & audio analytics platform Pex tweeted the average length of a podcast episode fell from 45:44 in 2015 to 35:27 in 2020. The trend of shrinking episode length is there.

Third, the idea of short-form content is already getting a lot of attention, although in a different field – it’s Quibi with $1.75 billion raised to produce short-form mobile-only TV series.

UPDATE: Quibi is shutting down, but I think everybody knows it’s not because the TV shows were too short – it’s probably their mobile-only approach and vertical video (all content had to be shot in a certain way to fit the screen in portrait mode = a lot of limitations & higher production cost) that killed them. Launch during the Covid-19 pandemic also didn’t help (you don’t really need short-form content when you’re sitting home the entire day) but I think they would’ve survived this if not for the mobile-only & screen stuff mentioned above.

Fourth, there already are some successful short-form podcasts like Six Minutes, so it isn’t completely uncharted territory.

The decision was made: I’m going to start the first short-form podcasting company. All podcasts will be 10 minutes or less.

I was aware my podcasts won’t be anywhere near the best ones quality-wise, and I wanted to build the company to sell it, just like Gimlet did.

So I needed something more.

I needed to create and represent the short-form podcasting movement.

One of the reasons companies are acquired is that they provide the acquirer access to a new (sub-) industry. If I started a regular podcasting company, I would have to be too freaking good to stand out among tons of others.

By being a short-form podcasting company, I wanted to create a league of my own. 

Sometimes the positions of brands are so strong not necessarily because their product or service is the best, but because they were the first, good, and fast enough to make their brand represent their niche.

That means I’d focus almost as much on promoting and associating my company with short-form podcasts as on the podcasts themselves.

Who knows, maybe it would have worked.


Dealing with software developers

Some of my observations and experiences I’ve gathered while working with multiple different developers on multiple startups:

Hiring a developer you haven’t worked with yet

Don’t hire a developer you haven’t worked with yet unless he comes with bulletproof testimonials. If possible, try to assign him some small side project where you can see him in action. 

Most red flags usually appear very soon, so working with him even for a short time will help you to better evaluate his suitability to work with you permanently.

If it’s not possible, make it at least clear that you’re hiring him for a test period.

It may be surprising to learn how many bad traits or habits a developer can have which will make working with him very complicated, no matter how good he is from the tech perspective.

Experienced vs Inexperienced

An experienced developer has already done projects (or at least features) similar to what you want him to do. This means that he will spend most of the time coding, not figuring out how to go about it. The code will be easy to navigate and build on. 

An inexperienced developer will encounter a lot of new stuff when working on your project. He will have to learn it first, and learning takes time. Part of learning is making mistakes, which will significantly delay development. He doesn’t know what the best practices are & how to properly structure the code – the software may work, but it could be a nightmare (or even impossible) to edit and develop further.

If a developer makes just one fundamental mistake and realizes it only after a few weeks, it’s likely the code will have to be rewritten from the ground up.

Motivation and Honesty

When a developer is motivated, he can do incredible things. If he isn’t, he can do incredibly little.

The tricky thing about working with a developer is that it’s difficult for you to tell whether the next 7 days that he requested to get something done are really needed – you have no way to know whether he wasn’t done by the day 2 and then just waiting until the 7-day deadline runs out.

I’ve seen this firsthand and also heard stories from programmers themselves. They were able to waste an unbelievable amount of time by lying about what they are (or are not) doing.

Try to find a developer with an intrinsic motivation to build things. For some developers it’s only a job, nothing more. For others, it’s their life mission to solve complex challenges and build great things, even if they’re often not going to be first in the line when the payday comes.

Having skin in the game helps, too. When a developer is a part of your early-stage startup and knows that he’s not going to get paid until you get the thing going, his motivation cannot be even compared with a motivation of a developer who’s paid by the hour and your success or failure would affect him only a little.

On the other hand, I’ve met a developer who was paid by the hour and worked like it’s his own project.

Try to find a developer with the right mix of honesty, motivation, and skin in the game. Some just need a reason to work hard, others won’t work hard anyway.


Try to find a developer who can make things that actually work. It’s natural if you stumble upon some hidden bugs, but when a developer tells you that the new feature is done and it doesn’t work AT ALL, it’s a problem.

There are multiple types of developers here:

  1. A developer that only sends you software for review that always works perfectly
  2. A developer that sends you software where all main features work and you will only find a few hidden bugs that need fixing
  3. A developer that sends you software that sometimes works and sometimes doesn’t
  4. A developer that sends you software that fails right at the first opportunity, even if he said that everything works

#1 is very rare, #2 is what you should be aiming for, #3 and #4 are bad – it means that the developer is lazy to spend a little time testing the software.

Ask your developer to always test the software before sending it to you for a review. This used to drive me crazy: I was told new version works, but it crashed right after hitting the first button.

It’s not just about driving you crazy though. A developer constantly delivering software that doesn’t work has negative time implications too:

You assign a developer a task and he says it’s going to take 2 weeks. After 2 weeks he delivers it and almost nothing works. So he says he needs another 10 days to fix it. After 10 days he fixes it and it works, but you find some little bugs that again need fixing – another 5 days. 

When you sum it up, you went from 14 to 29 days.

If you allow a developer to do this, he’ll see that the deadline for everything is always double of what you originally said. “I need another week” situations are a very, very slippery slope.

Little changes

Sometimes a developer changes a detail without consulting it with you because he considered the change insignificant and it was easier to code it that way.

This can’t happen. If a developer thinks there’s a better or faster way to do something, he has to consult it with you first – make sure he’s aware of it.

If you know what you want, every single detail in the assignment is there for a reason. Changing a few of them, even a little, can result in a real mess in the final product.

When something isn’t clear

Sometimes you forget to specify some small details about the feature. 

There are 4 types of developers in this situation:

  1. A developer that will instantly get in touch with you to ask how to proceed
  2. A developer that will not get in touch and wait until you do (inquiring how it’s going or whether it’s done) just to tell you that he doesn’t know how to proceed
  3. A developer that will solve it himself, but badly
  4. A developer that will solve it himself, mostly well

You want to work with either #1 or #4. #2 may indicate that he has no motivation to get it done ASAP and #3 will probably just need to be told to do #1.

Be ruthless

When you finally hire a developer and you see that it doesn’t work how you expected, find another one. I can’t stress this enough.

You can try to “talk to him” but from my experience, it rarely works – things may improve for some time, but it eventually gets back to the old ways.

I’ve seen months wasted by delaying the decisions to replace a developer. When we finally did that, in one case a new developer had done more work in the first 2 weeks than the old one did in the last 3 months. 

Sometimes it’s difficult to realize how big the difference in productivity between a bad and good developer can be.

If you find yourself in the “it’s going to be done soon” mode for too long, you shouldn’t hesitate to make the change.

Final point

You’re not going to get anywhere without good developers. Try to find the best you can. Having a great developer makes everything so much easier. It gives you confidence that you don’t have to worry about your software because it’s in good hands. You know that if there’s a problem in a published version of the software, he will be able to quickly fix it.


Challenges of new sharing economy platforms

My rather short stint with Kaktus App (check my bio) allowed me to dig deeper into the world of sharing economy. Here are the major problems that I’ve encountered and that every new sharing economy platform will face.

Customer trust

One of the biggest challenges for every new sharing economy platform is to convince new users that it’s stable, serious, safe to use, and there to stay – in other words, that it can be trusted. After all, trust is one of the main pillars of the sharing economy.

When starting, it’s not easy to spot and fix all aspects of the service that may indicate to customers that there may be something risky about using it – put differently, it’s difficult to get them all right.

The trust problem new platforms face is slightly related to a certain standard that people nowadays got used to using Uber, Airbnb, and other established sharing economy platforms where the providers (and even customers) are screened very thoroughly to secure safety and integrity of both sides and customers are often insured or have other forms of guarantee if something goes wrong.

New platforms probably won’t be able to afford to have even the more fundamental things on such level, which brings me to the next point.

Chicken and egg problem

Who should new platforms try to acquire first? Providers or customers?

If providers, what are they going to tell them when there are no customers out there yet, and it can take weeks or even months to get first order? 

If customers, who will be they able to choose from and hire when there will be no providers?

This problem has another sub-problem: Since new platforms should obviously go for the providers first, what kind of providers should they focus on getting? Where are they going to set the bar?

If they decide to set it too low (anyone can register and start offering the service) they will end up with a lot of low-quality providers which will be an instant turn-off for the potential customers, will damage their image and can even get them in trouble if some provider does something illegal. Even if they manage to get a few solid providers along the way, they will be lost in the sea of low-quality ones.

If the bar is set too high (long registration process, waiting period to get approved, check of the government-issued ID) much fewer providers will register because a) they just won’t spend so much time registering on a platform that is just starting and has no customers and b) they won’t trust the new platform enough to send them copies of their IDs – after all, nobody knows how they are going to use them or how securely are they going to be stored.

It also depends on how exactly and at what terms is the new platform going to connect people – you don’t need a voiceover artist from Fiverr to have a verified government ID, but you’d expect that an Airbnb host will.

Payment processing

The sharing economy is considered a high-risk business model by virtually every payment gateway, which may be even compounded if a new platform is simultaneously in one of the high-risk industries for payment processors as well – for example, travel. 

This means:

a) Some will decline to work with new sharing economy platforms outright

b) Some will work with them only if they can demonstrate that they have a history of processing a significant amount of money (couple tens of thousands) in few consecutive months without a huge percentage of chargebacks or other problems

c) They may have to go with a payment gateway that is focusing on high-risk businesses and has much higher processing fees

d) They may have to go with a small or little well-known one that often has various technical or financial limitations (no/bad integration for mobile devices, limited analytics, long payout period combined with high and long-term rolling reserve, etc.) forcing them to make various workarounds in the payment process – every unnecessary or unusual step during the payment process will have “oh shoot what’s this” effect on some customers that will better leave because it won’t simply look right.

Long payout period and rolling reserve (payment gateway holding a certain percentage of the money for a certain time before releasing it to the platform) will also cause problems with sending money to providers – how can a platform pay them when they don’t have (all) the money available yet? 

It can either have a bunch of money set aside to pay providers faster or pay them with huge delays. And don’t forget there are various operating expenses the platform has to pay for, too.

If their chargebacks to transactions ratio gets above a certain percentage, the payment gateway will deactivate the payment processing (often with no heads-up), and the platform will suddenly have no way to process the payments. Getting a new payment gateway can take 1-2 weeks (assuming they can find one), so it’s not like they can just switch to another one unless they have it fully operational and ready to be used in reserve.

If the new sharing economy platform isn’t based in the US or another well-developed country where most payment gateways have chosen to operate, it is at a big disadvantage and potentially in big trouble – some countries are simply no-go zones for payment processors.

Uncertain future of contractors

The vast majority of providers on the sharing economy platforms are the platform’s independent contractors, which means that the company is not responsible for anything but paying them. People that “work” for a sharing economy company full-time have no employment benefits employees use to have (for example subsidized health insurance and retirement plans) and part of them want the government to take action to ensure the same or similar benefits for contractors, too.

We’ve seen this recently in California where they passed the AB5 law restricting contractor’s working hours, which is probably not really what contractors wished for since a lot of them outside the sharing economy industry were let go by the companies they were previously “working for” as contractors (the now-famous case of Vox letting go hundreds of freelance writers), even though the original idea was to “force” companies to hire them as regular employees.

Even after what happened in California we can expect another efforts to push (not only) sharing economy companies to classify their contractors as regular employees, or at least provide them the same or at least similar benefits. If this happens, sharing economy companies will see a huge increase in costs. A regulation like this will destroy one of the biggest advantages sharing economy platforms have over traditional companies.

Additionally, it will probably cause the need to raise the bar to entry for new providers on sharing economy platforms because companies wouldn’t want to provide employee-like benefits to everybody who signs up. The original idea of a sharing economy was that people are going to be doing this part-time as a gig and nobody will complain about not having employment benefits because everybody has a full-time job that provides it. With the rise of sharing economy more and more people had seen that it’s already big enough to replace their full-time job – and that’s where the problem started.


Getting your product featured on Product Hunt

Before submitting our app I was looking for some tips on how to get a product featured on Product Hunt – the only thing I found was that it helps to have someone well-known in the PH community to hunt it.

It looked pretty clear to me that there won’t be any useful tricks available, so I just submitted the app and left. When I came back in a few hours, I’ve seen the notice that it’s going to be featured the next day.

I was shocked because it gained absolutely no traction before being chosen. It looks like PH people go through every submitted product that day and if you’ve made something really good, they’ll notice.

We even got a very nice comment – 

But as it turned out, being featured doesn’t help that much unless people LOVE (and upvote!) your product – we got only 45 upvotes and ended up almost last among featured products that day.

I don’t remember and don’t have access to the specific numbers PH helped to generate anymore, I just know that they were pretty disappointing – just a few tens of website visits, few tens of App Store views and few downloads.

The bottom line? Don’t look for ways to play the system, just create something great. And if you get featured, don’t get too excited yet because what really matters are the upvotes.

[Please note that I’m longer with Kaktus App – you can read more about this in my bio]