Sign in

This is an incredibly biased commentary about Duolingo’s product right after the IPO.

I am a huge fan of this product (not just as a consumer, but also as a product manager).

Not every growth engine works for every product. A referral engine is one such tool in your toolbelt.

In this post, I will highlight some key characteristics of referral models.

Common Variables

Most referral programs have generalizable variables that need to be considered:

When we think of “product debt”, we tend to default to only technical issues such as scaling your servers or refactoring your code.

There are many types of debts. You will take some of them on- intentionally or not.

Let’s start with some definitions


Debt is a deferred payment, or series of payments, which differentiates it from an immediate purchase.

In product management, you are taking a loan against your future time.
You are choosing to solve for Task A rather than Task B right now.


Bankruptcy is a situation where one is no longer able to repay their debts.

Engineering in marketing is such an underutilized resource for software companies.

This isn’t a post about “Growth Hacking” or about the “intersection” between product and marketing.

I’m not sure if there is an industry term for it yet but it sits somewhere outside of your product and before your marketing team.

Isn’t this just “Inbound marketing”?

Well, I guess it’s a specific type of tactic

It still serves as a top-of-funnel tactic like email capture on blog posts and ebook downloads but they tend to be more unique and much harder to copy.

We are abusing prototypes. (I mean as an industry, not just me personally)

Prototypes are cheap and easy ways to test product usability.

1. Some things are NOT worth testing

They shouldn’t be used to test
(a) Desirability of a product idea
(b) Well-established interactions (e.g. logins)
(c) Single page applications

They should be used to test
(a) Complex interactions
(b) Completely new functionality
(c) Changes in workflow, technology, or design.

2. Move away from Lorem Ipsum

You want to test how users will respond to the interface. It isn’t a fair experiment when only the call-to-actions are clear.

You want to solicit a real response or close to it

3. Stick with common terms & icons

This is a…

It’s trite at this point to say “Launch quickly and Fail fast”. We all know the following quotes:

Move fast and break things.
- Mark Zuckerberg, Facebook

If you are not embarrassed by the first version of your product, you’ve launched too late
- Reid Hoffman, LinkedIn & Paypal Mafia

The question is, is this gospel?

Is it alright to ever delay the launch of your MVP?

Spoiler Alert: We are delaying the launch of avopos.

Scars from the Past

I think there are good reasons for the “launch fast” mentality. …

We all have this fear when we start out. Our MVPs are feature-poor and only serve a small segment of the entire user base.

When compared to more mature products, you might think…

“This is just a feature”

Not every feature will make it to product-market fit BUT,
I think there are some strategies that might work for turning these “features” into profitable startups.

  1. “Platform-for-foundation” Strategy
  2. “Attached-to-revenue” Strategy
  3. “Platform-for-distribution” Strategy

Strategies that might work

1. “Platform-for-foundation” Strategy

Adopt this strategy if
(a) you are solving latent problems for more mature user groups and,
(b) adding value to the core experience.

I always start from the Jobs-to-be-done framework. I don’t think that great startup ideas pop out of nowhere- I think they are discovered by observing jobs that arise in the world.

By the way, that’s also how we decided to build avopos.

Great products (or services) succeed because they do the Job-to-be-done better than the alternatives

Recommended Pre-read: How to build great products

Here are some frameworks for discovering startup ideas using the Jobs-to-be-done (JTBD) framework:
(1) Bundling
(2) Unbundling
(3) Lower Coordination Cost
(4) Luxury at scale
(5) Reduce Adoption Friction
(6) Low NPS incumbents
(7) Solving issues due to older solutions
(8) One improved…

When I picked up coding, technical software tasks immediately became less daunting. The unfortunate side-effect was that I started developing the unhealthy mentality that features were “cheaper” than they were in the past.

Huge mistake.

Features (even small ones) are not free.

Why is that?

Overview of Cost

We are incredibly biased towards short-term thinking. We get so caught up in the short-term pain that we lose sight of the long-term side effects.

Perceived Cost

When we contemplate new features, we tend to consider only the following costs:
(1) Time required to scope the feature
(2) Time required to design the feature
(3) Time required to develop the…

Product marketing is one of the many competencies required to bring a product to market.

Your job is to basically answer one question:

What does your product or service do?

The reason product marketing is difficult because you are trying to select the “goldilocks” level of abstraction for your product’s description.

Your answer might be too…
(a) Specific vs Broad
(c) Undifferentiated vs Confusing
(d) Too complex to understand vs Too simple to be valuable
(e) Functional vs Emotional
(f) Etc.

Fu Fei

Full-time PM. Part-time Indie Hacker. I write about my own SaaS journey + Product Management lessons for bootstrappers & early stage startups.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store