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.
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.
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.
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.
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
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.
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.
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:
(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.
Features (even small ones) are not free.
Why is that?
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.
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