Growth Funnels

24 Sep

You spend a ton of time building a product to solve a particular problem. You launch. Then, either the kinds of people whose problem you are solving never arrive or they arrive and then leave. You want to know why because if you know the reason, you can work to address the underlying causes.

Often, however, businesses only have access to observational data. And since we can’t answer the why with observational data, people have swapped the why with the where. Answering the where can give us a window into the why (though only a window). And that can be useful.

The traditional way of posing ‘where’ is called a funnel. Conventionally, funnels start at when the customer arrives on the website. We will forgo convention and start at the top.

There are only three things you should work to optimally do conditional on the product you have built:

  1. Help people discover your product
  2. Effectively convey the relevant value of the product to those who have discovered your product
  3. Help people effectively use the product

p.s. When the product changes, you have to do all three all over again.

One way funnels can potentially help is triage. How big is the ‘leak’ at each ‘stage’? The funnel on the top of the first two steps is: of the people who discovered the product, how many did we successfully communicate the relevant value of the product to? Posing the problem in such a way makes it seem more powerful than it is. To come up with a number, you generally only have noisy behavioral signals. For instance, the proportion of people who visit the site who sign up. But low proportions could be of large denominators—lots of people are visiting the site but the product is not relevant for most of them. (If bringing people to the site costs nothing, there is nothing to do.) Or it could be because you have a super kludgy sign-up process. You could drill down to try to get at such clues, but the number of potential locations for drilling remains large.

That brings us to the next point. Macro-triaging is useful but only for resource allocation kinds of decisions based on some assumptions. It doesn’t provide a way to get concrete answers to real issues. For concrete answers, you need funnels around concrete workflows. For instance, for a referral ‘product’ for AirBnB, one way to define steps (based on Gustaf Alstromer) is as follows:

  1. how many people saw the link asking people to refer
  2. of the people who saw the link, how many clicked on it
  3. of the people who clicked on it, how many invited people
  4. of the people who were invited, how many signed up (as a user, guest, host)
  5. of the people who signed up, how many made the first booking

Such a funnel allows you to optimize the workflow by experimenting with the user interface at each stage. It allows you to analyze what the users were trying to do but failed to do, or took a long time doing. It also allows you to analyze how optimally (from a company’s perspective) are users taking an action. For instance, people may want to invite all their friends but the UI doesn’t have a convenient way to import contacts from email.

Sometimes just writing out the steps in a workflow can be useful. It allows people to think if some steps are actually needed. For instance, is signing-in needed before we allow a user to understand the value of the product?

Seven Rules of Technical Management

31 Aug
  1. Assume that everything is being done sub-optimally. Probe everything.
  2. Push people to explain things as simply as possible.
  3. For anything complex, ask people to write things down in plain english.
  4. Get perspective from people with different technical competencies.
  5. Frontload your thinking on a project.
  6. Define the API before moving too far out.
  7. Do less. Do well.

The unsaid golden rule: hire competent people. Other virtues matter but competence generally matters the most in technical roles.

Make Phone Meetings Great Again!

20 Oct

Remote teams live and die by the phone meeting. So how can we prevent death? Channel Rumsfeld. Begin with known knowns of conducting a successful meeting: having a clear agenda, a discussion leader, and ending with a summary. Do those well. Then try out some ideas to address well-known challenges: disengagement, social friction, exclusion, time wastage, and inability to follow what’s going on.

  1. People on the phone can’t always tell between the two uses of brief silence—a brief pause, and signal for opening the floor for discussion. The speaker can address the issue by signaling the end of speech with a phrase such as ‘I am done.’ A speaker may start the speech by noting: ‘at the end of what I have to say, I will formally open up the floor and go around alphabetically among those whose speakers are unmuted.’
  2. Having ‘too many’ people = wasting people’s time + disinterested participants. How many is too many? The maximum number of people who can productively engage when everyone is expected to contribute is probably as low as 4–5. What do you do when you have a large team? Divide and conquer. Split people into small teams and share notes.
  3. Prevent or Cure Rambling as side effects are the same as above—time wastage and disinterest. If people are having trouble articulating, the discussion leader should take on the responsibility to energetically understand the point people are trying to get at. The discussion leader may also refer the person to the shared document to sketch out the idea and try again.
  4. Stuff in advance that everyone actually reads is important. Just tell people if you didn’t find time to read + independently think, just opt out (semi-private opt-outs with emails to meeting organizers should be allowed). The job of a meeting is not spoon feeding.
  5. Keeping people on the same page:
    • Visual aids, e.g. slides, are useful in bringing people on the same page.
    • Taking notes on a shared screen can also help see people that progress is being made. The document can be shared and that allows others to contribute and organize simultaneously.

Most importantly, avoid meetings when you can. If the aim of meeting = transferring information, it only makes sense to have a meeting < 10% of the times. Alternatives = write out a document, or create a slideshow or a video and send it along.

(Software) Product Development Cycle

6 Mar
  1. Solicit Ideas
    Talk to customers, analyze usage data, talk to peers, managers, think, hold competitions, raffles,…
    For each idea:
  2. Define the idea
    Write out the idea for clarity — at least 5–10 sentences. Do some due diligence to see what else is there. Learn and revise (including abandon).
  3. Does the idea make business sense? Does it make sense to the developers (if the idea is mechanistic or implementation related)?
    Ideally, peer review. But at the minimum: Talk about your idea with the manager(s) and the developers. If both manager(s) and developer(s) agree (for some mechanistic things, only developers need to agree), move to the next step.
  4. Prototype
    This is optional, and for major, complex innovations that can be easily prototyped only. Write code. Produce Results. Does it make sense? Peer review, if needed. If not, abandon. If it does, move to the next step
  5. Write the specifications
    Spend no less than 20% of the entire development time on writing the specs, including proposed functions, options, unit tests, concerns, implications. Run the specifications by developers, get this peer reviewed, improve, and finalize.
  6. Set Priority and Release Target
    Talk to the manager about the priority order of the change, and assign it to a particular release cycle.

  7. Who Does What by When?
    Create JIRA ticket(s)
  8. Code
    General cycle = code, test -> peer review -> code, test -> peer review …
    MVP of Expected Code or Aspects of good code: ‘Code your documentation’ (well-documented), modular, organized, tested, nice style, profiled. Do it once, do it well.