Why is building shiny tech more popular than tackling core problems head-on?

I’d guess because the most important trait for the latter is utterly stupid + painful amounts of determination.

For instance, here are some of the brick walls we bashed our heads against at Wave:
(Context: we’re building a mobile money system—a network of agents where people can deposit, withdraw, or send money—to replace banks in sub-Saharan Africa, where most people are unbanked because most banks are terrible.)
Our first attempt was to launch it as a "feature" of our existing, successful international money transfer product (sendwave.com)—you could send money from the US to our agent network in Ethiopia.
This failed because there was a massive currency black market. If you used informal remittances you could get a rate 25% higher than we could legally offer.

So we gave up and decided mobile money would be a ~completely separate business, built from scratch.
But launching separately failed too because there wasn’t enough demand for money transfer from Addis Ababa, where we started.

We learned the biggest demand was in the Somali region (sending money is a big part of Somali culture). So we uprooted our operations and moved there.
Our Somali region launch failed because the internet wasn’t good enough. We originally built a smartphone app, which worked ok in Addis, but was non-functional even in Jijiga, the Somali region’s capital.

So we rebuilt the system using USSD (en.wikipedia.org/wiki/USSD) instead.
That had amazing traction, but eventually failed too because we ended up having to end our pilot in Ethiopia (long story).

We looked at other markets and decided to try Nigeria, since it was the biggest single market in Africa and didn’t have good mobile money yet.
The Nigeria launch failed because our money transfer value prop wasn’t as good.

That was because banks were better there—they allowed instant interbank transfers. So many people used a bank account like mobile money (even if they lived really far from a bank branch).
So we rebuilt ourselves again—people could link their bank to Wave and use our agents to withdraw.

That failed because it was too hard to build anything interesting on top of it. We wanted to be NG’s economic rails, not a glorified ATM.

So we up and moved again, to Senegal.
That failed before launch: One of the telecoms had a big competing mobile money system. So we couldn’t get USSD like in ET/NG.

We ruled out smartphones due to low market share. Instead, we built a flow where users scanned an NFC sticker (en.wikipedia.org/wiki/Near-fiel…) at the agent.
Stickers failed because they were too hard to read if attached to a metal phone. Plus the NFC readers we gave to agents kept breaking and were a huge pain to work with.

So we gave up on NFC and redesigned based on cards with QR codes printed on (plus SMS as 2nd auth factor).
Once that was going well we tried to expand into using Wave to pay for things at shops. We spent months on a pilot project.

It failed because even shopkeepers didn’t consistently have smartphones. It was too hard to get a critical mass of Wave merchants in one place.
So we re-focused on scaling the QR card thing, which was still trucking along. But that failed too because we didn’t know how to run an agent network at massive scale.

So we hired someone who could—one of my colleagues connected us to someone who’d scaled 4 other agent networks.
And... then everything worked! We plastered the country with agents, built a companion smartphone app for the 50% of people that did have phones, added the ability to pay bills with Wave. Growth took off and hasn’t slowed down yet.

Finally!!
But... that’s 10 major failures over ~4 years. It was HARD to make it through these. Each one felt company-threatening.

Luckily for us, Wave’s founders had a totally unreasonable-seeming amount of conviction (100% justified in retrospect!!) and pulled it through.
How did they end up with so much conviction?

Probably related to the 2 years they spent building *ten plus* failed social mobile apps before finding their original breakout success (Sendwave—intl $ transfer).

They’d already been through this and could see the light at the end.
(Fun fact: the Wave name and penguin logo were originally for one of the social apps! It was a mobile group video chat app. They reused the name/logo for money transfer because people liked the branding more than the rest of the app 🙃)
The other part that gave us conviction, of course, was the looks on people’s faces when we *did* manage to build something they wanted.

One conversation with someone for whom your app has changed their life will get you through a lot, lot, lot of bad days (or years).
I think that’s our most unusual strength—more than being great at product/tech/ops—we just keep. f’ing. trying. when it seems like we should give up and go home.

You can read plenty of platitudes about the power of determination, but I hope this puts some color to them :)
Addendum: My partner correctly points out that being unreasonably determined on its own isn't enough. You need to be determined *and smart about it.*

If you're determined about the wrong thing, you'll end up like the Time Cube guy instead of like Wave.
I think PG's "relentlessly resourceful" is the best concept-handle for the right attitude to have: paulgraham.com/relres.html

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Ben Kuhn

Ben Kuhn Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @benskuhn

14 May
More late-stage companies are switching from four-year vesting to one-year grants. Stripe, Lyft, and now Coinbase (blog.coinbase.com/how-coinbase-i…).

Seems like a good time to talk about why being an early startup employee is (used to be?) a much better deal than it might seem:
1. Picking winning startups is actually not *that* hard: benkuhn.net/vc-emh/ It's not *easy*, but some VCs, and TechCrunch award voters, do it regularly.

"If it's not hard then why aren't you rich?" Because plebs can't invest at those valuations, only name-brand VCs can.
("Why do name-brand VCs get a good deal?" Because many companies don't optimize very hard for valuation when fundraising. Instead they try to minimize distraction, risk of down rounds, etc. See post for a more fleshed-out argument.)
Read 10 tweets
30 Mar
Hot take: the outside view is overrated.

(“Outside view” = e.g. asking “what % of startups succeed?” and assuming that’s ~= your chance of success.)

In theory it seems obviously useful. In practice, it makes people underrate themselves and prematurely give up their ambition.
One problem is that finding the right comparison group is hard.

For instance, in one commonly-cited statistic that “90% of startups fail,” (national.biz/2019-small-bus…) “startup” meant all newly-started small businesses including eg groceries. Failure rates vary wildly by industry!
But it’s worse than that. Even if you knew the failure rate specifically of venture-funded tech startups, that leaves out a ton of important info. Consumer startups probably fail at a higher rate than B2B startups. Single-founder startups probably fail more than 2-founder ones.
Read 14 tweets
28 Mar
A lot of managers (including me!) find it hard/scary to give critical feedback.

I realized recently that this is often downstream of a less obvious blindspot—giving people enough *positive* feedback! If you've done that, critical feedback "magically" becomes much less fraught.
Basically, the hard part of giving people critical feedback (at least for me) is worrying that it'll make them feel bad (as opposed to motivated to improve). The biggest thing that makes people feel bad is worrying that their manager thinks they overall suck at their job.
So you need to give positive feedback not just for things that are *surprisingly* awesome (which I think is many managers' default), but frequently enough that the positive:negative ratio accurately reflects how good they are at their job.
Read 9 tweets
26 Mar
This is another great takeaway from last thread, which I *should* have learned from changing jobs, but actually took ~20 more cycles on the motivation roller coaster to realize.

For me, bad focus was ~always a response to circumstances, even when I wasn't consciously aware!
My first years at Wave, I repeated variants of the following ~monthly:
- notice I'm stressed/unfocused
- "huh, having an off day"
- go climbing, read books, etc.
- still stressed
- gripe to boss eg "accounting sucks"
- boss helps fix accounting problem
- ✨happiness returns✨
Eventually I started interpreting stress/unfocus as a sign, not that I was having a bad day, but that I was working ineffectively or on the wrong thing. Eg, I'd know I needed to be hiring faster, but kept getting distracted by other, less important, more urgent projects.
Read 6 tweets
24 Mar
One thing that surprised me when I switched plans from "earn lots of $ and donate" to "build important things," is how much more productive I became.

I thought if I was earning the $ by doing intellectually interesting work I'd stay motivated. Turned out that wasn't true!
Actually, it was even worse—I *thought* I was motivated while I was doing plan A, and only when I switched did I even realize *how motivated it was possible to be.*

Several friends had this experience as well. Makes me wonder how many people are stuck in that state.
(For example, I never thought I'd be pumped enough about work to live for 1+ yr in a country where I didn't speak the language! Or to have the stamina to spend 20+hr/wk on the phone with an accounting firm. Or etc.)
Read 11 tweets
17 Mar
People ask me for a lot of advice on what to do about technical debt. Here some things I’ve learned about how and when to prioritize fixing bad code:
1. Distinguish global vs local problems.

Local problems are things like a poorly-implemented module—it slows you down if working on that module, but is fine otherwise. Global problems are things like “we use database transactions wrong” that infect everything.
2. Fix local problems the next time they get in your way.

(i.e. trust that they’ll get solved eventually by a “make the change easy, then make the easy change” process.) Leave TODOs in the code, deprecate methods, etc. as breadcrumbs for anyone else who might want to fix.
Read 10 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(