Monthly Retrospective - August 2024

By Max Sherman ยท Sep 5, 2024

Increase the rate of features shipped

Stats

  • Not sure how many hours worked
  • Streamed 0 hours on Twitch (-100% M/M)
  • Stripe payouts $2,134.02 (+23% M/M)
  • 510 Twitter followers (+7% M/M)
  • 171 Twitch followers (0% M/M)

Building an engineering team

Things are going well. I spent some time this month thinking about how to set goals. There's a meme in the software engineering world about how it's bad to evaluate performance based purely on lines of code written. I agree with this, but ultimately I think you do need to have a framework to think about how to evaluate performance, and right now (at least for the phase the business is in) this is the right metric to look at.

I can envision a future where the (linear) commit history of the repo has commits added orders of magnitude more frequently than we do now. This is a leading indicator for product development, features shipped, performance and reliability improvements, and so on.

It's much more useful to set a goal for engineering around this metric because it is controllable. For example, "create one PR per day" is simple to operationalize. All you need to do is have a reliable process for creating work (e.g. find an existing Github issue), and a reliable process for doing that work (e.g. reproduce a bug locally and fix it).

Compare that to the goal of "doubling revenue". It's much harder to operationalize this because it requires experimentation and time. There is a degree of luck involved, and there's no clear roadmap that I know which will produce this outcome directly.

I do believe that if we consistently ship new features, bugfixes, perf and reliability improvements to production, then we will guarantee an increase in revenue over time, so number of PRs created is the way to operationalize more revenue. It's just not going to be a linear path probably.

As we ship, we will learn more, and this will compound over time.

I'm still interviewing for a second engineer. The goal is to find someone who raises the bar of the team.

One time payment

We shipped a new payment option to pay for credits as a one time payment instead of a subscription. There were some issues here and our paywall conversion rate cratered. We've reverted the change, and the paywall conversion rate seems to be recovering.

As the team and product grows, a muscle we need to build is responding quickly to drops in metrics (like paywall conversion rate). This won't be the last time it happens, and we will have more opportunities to get reps in. Over time, we need to get better at shortening time-to-realizing-the-problem, and time-to-fixing-the-problem.

Two takeaways I have are:

  1. When large features ship, we should check Posthog recordings and analytics a few times in the days following. This will help us understand what follow up work is needed and identify problems. A great place to do this is in 1:1's
  2. Changes to the paywall are extremely high leverage. Two of the largest moves in conversion rate are from paywall changes: lowering prices from $27 -> $15 (increased CR), and adding OTP (decreased CR). An extra degree of caution is needed when we make changes to the paywall. We should get into the habit of running A/B tests for paywall changes.

Optimizing time to paywall

We need to focus on performance so that number of users who make it to the paywall increase, and also these users will have a heightened perception of our product delivering them a result fast. Fast delivery is a core value prop, because a large part of the pain of writing minutes comes from how long it take to do manually. Other core value props are that it's boring/tedious/not fun, and that we can also do a much better job than someone who does it manually.

Increasing Perceived Liklihood of Success

I think a big reason why people do not pay is that they are not sure they will get the desired outcome. We offer a partial transcript, but we do not show partial meeting minutes. There are some technical challenges to overcome here, especially if we want to do this fast, but I think it would go a long way to increasing users' confidence that paying will guarantee them a great outcome.

This is a priority.

Offering Hosting

In the future, we may want to expand into B2B territory to upsell organizations on dedicated website integration for hosting past meeting minutes for public (or internal) consumption. We're not there yet, but it could be an interesting direction to expand the business.

Increasing Import and Export Capability

We want to increase the number of ways to import and export inputs and outputs. For example, being able to import meeting recordings and transcripts directly from Google drive, Zoom, and MS Teams. This would also eliminate any slow network issues we face from customers on slow internet connections.

Similarly for exports, we can make the product more valuable by making it easier to use. For example, an option that allows users to export meeting minutes by emailing them.

Paywall Abandonment Emails

We shipped an automated email sequence for paywall abandoners. Next steps here are to find ways to optimize the campaign, likely by A/B testing copy, and also generating meeting minutes in the background, and attaching them to emails. Then seeing if we can convince more people to come back because they like what they see.

Goals for September

  • Hire and onboard another engineer
  • Ship two major features