Build in Public: PluFin, Sprint 2
**I’m launching a newsletter in 2022 called Personal Finance in the Blockchain Age. It would make my day if you sign up.**
Wow did this week fly by. I spent some timing thinking about how to simplify these posts, but I failed at that. I enjoy documenting what I’m doing since I can return to this and going through my process later — finding ways to improve / iterate my thinking.
If you haven’t already, please sign up for the Jan 1, 2021 Beta launch for PluFin.
Key Stats
As I started sharing last week’s article on Twitter, I realized I should be open about data for a variety of reasons. At some point I’ll write up some thoughts on open data, especially while you’re building and seeking Product Market Fit (PMF). Pre-launch, the main metric is the audience that I’ll have for the Jan 1 email Beta launch. Post-launch, it’s Paid Subscribers.
Email signups: 62 (24% WoW). Goal for Jan 1, 2021: 1,000
Paid Subscribers: 0. Goal for Dec 31, 2021: 10,000
Highlights from Sprint 1
This was a good, but challenging sprint. I estimated 9 story points of work, but I was way off with my estimates, 3s should have been 5s, etc. I was able to build out each of the tickets plus complete the first round of testing on my local machine. But as the week wore on, and I did some planning for the rest of the Beta work, I realized that there were more use cases I need to consider.
It wound up becoming a little over-complicated, and I was not able to keep a mental model of all the use cases in my head. This would NOT be the first time, but it was compounded by the fact that my codebase was now so complex I couldn’t remember writing parts of it. An inefficiency that I’ve always felt can be remedied with good documentation.
So I decided (yesterday) to begin documenting the User Acceptance Testing scenarios (which is time-intensive) to keep track of the various use cases I needed to test.
For example, I realized this week that I will need to limit the number of free tier users I allow for the Beta. I simply don’t have the resources to handle a surge if one were to happen — either with cash to pay for the free tier users or customer support people to handle any questions / issues. And that will be true for at least a year.
But that was too limiting in my view. I have this KR1 of 10K Monthly Paid Subscribers by the end of 2021 (I’ll try to do a proper OKR process as 2021 gets closer). If I only allow 100 Beta subscribers that entire time, I’d never have a shot at achieving my KR1. I’m also limited by resources.
So I need a profitable way to allow more Beta subscribers. And the only way to do that is to convert Paid subscribers and to then use some of that monthly margin to increase the number of Beta signups. This puts my primary focus on building the product so that it will add enough value that users feel like it’s worthwhile to pay for it. It aligns PluFin and the customers’ incentives, which is increasingly important to me.
Because of this new series of fairly complex use cases, I had to consider new use cases for who could purchase, upgrade, downgrade, cancel, counteroffer, and change their credit card.
The User Acceptance Testing (UAT) helped streamline everything, but I have some technical debt since the current implementation is not as streamlined as I had begun to model it later this week.
As I went through the UAT, I fixed a TON of bugs. Nearly each use case had at least one bug, because I had built it earlier in the week and then decided to change some details. But I worked through and validated 23 use cases on my local instance, so I’m feeling good about testing this in production tomorrow.
At this point, it’s safe to say that PluFin will launch with a self-serve upgrade, downgrade, cancel, counteroffer, and change credit card experience. It isn’t sexy, but this core functionality will mitigate customer service requests so that I can focus on building vs firefighting.
One last thing to note. It’s been two sprints and I haven’t talked about the product. My focus for the last week and the week ahead is narrow: Make Payments and Bank Connections work.
This is fairly complex code. It’s important to get this right. The added benefit is that having a solid foundation will make it easier to add and handle new use cases, and it will reduce disruptive fire drills as well as reduce distractions by offering self-serve options out of the box.
However, once I’m done with this core code, I’ll be picking my head up to think about the positioning for January, clarify what I’ve built / the limitations / the vision, map out the marketing plan, and setup a process for customer feedback (including Calendly and Zoom chats).
And to round out the year, I’ll review the current experience, add some additional metrics / calculations, and create an onboarding experience that helps identify beta users who will spend some time giving me feedback. Because ultimately, that will be the most important part for January.
But at this point, the plan I’ve started forming in my head seems to be a little more ambitious than I have time to execute. That’s going to be my biggest concern heading into a Sprint 2 where I ALREADY didn’t complete the work for Sprint 1. And I am adjusting my story point estimations, because this week the 3s should have been 5s. Lots of unknowns heading into Sprint 2. That’s startup life.
Sprint 2 Plan
Same drill. I’m the PM, Eng, Designer, and Scrum Master.
Product Manager
So we got behind on completing the Subscriptions work last week. I had not consulted with our Product Marketing Manager about the launch plan (I’m also the PMM), but once I started laying out the next few weeks PRIOR to the Jan 1, 2021 launch, I realized that there were more use cases that needed to be considered.
And that created more work for engineering. This is going to happen as I do this by myself since it’s better to build / make progress regularly and fix things vs planning so much that you execute rarely (which very different from what I’d be doing if I was only focusing on ONE of these roles vs 5+). So this will likely be a recurring theme until I’ve created an infrastructure that is flexible to the various changes.
Once I complete the Subscriptions / Payments testing in production, the focus of this sprint will be all about deleting accounts and connections in Plaid, Auth0, and Mailchimp. I spent time planning everything for the Beta launch at a high level, so I didn’t get a detailed plan ready for Sprint 2.
I’ve always wanted to give users the ability to just delete all of their data. While I already created the purge button to delete your transactions info (in case you want to start fresh), I’ve been envisioning another button that deletes your data, deletes your email from email campaigns, deletes the plaid account connections, deletes the email you use to login. Everything. I call it the Nuke button. Because once you press it, nothing survives. We won’t even know who you are. We’ll be like Dory in Finding Nemo.
This is important to me, because I personally hate not having this functionality in a product. Especially one that is asking me to share so much data. On top of this, regulations are being passed that essentially ask companies to give users an easy way to control their data. I’m not going to get it perfect, but I want to make a transparent good-faith effort. And giving the user complete control to fully delete all or some of their data also winds up saving me time and money.
In summary, it will minimize legal headaches if we scale, reduce customer support help inquiries, and save time / money when used. Sounds good to me.
So that’s what I’m going to build this week. A way to delete Plaid bank account connections and data plus a way to delete a user in Auth0 so that they don’t have access anymore. Mailchimp users will need to be deleted from the campaign.
Some info will need to be retained (like transaction info in Stripe). So I need to figure out what data from the user will be retained so that this can be properly communicated / acted on.
Honestly, the MVP of the Nuke button will come with some acknowledgement that there may be data that we don’t delete since I won’t have done a comprehensive sweep of the system for a bit. Any data that we may retain is not intentional. If this happens, we’ll notify you and be transparent about what happened and what we’re going to do. Remember, this is all in beta, so I’m adding features as fast as possible.
Engineer
The new use cases caused a lot of new work. The Stripe use cases were fairly easy to troubleshoot in comparison. And I’m seeing at least 1 use case that is buggy, so I’ll need to fix that tomorrow. Hopefully I can complete the production testing tomorrow. It’s going to be tight. Then I get to focus on the Plaid API, which has proven to be a little challenging for me — there’s a ton of work to make that work better.
In late Aug /early Sept I screwed up by creating some Plaid bank account connections in production and then deleting the key in the database. This was around the time I realized I had more work to do with Plaid. Since then, Plaid, thankfully, sent me the keys (5 keys for the same account), so now I need to go through the process of deleting them.
So I’ll use those account keys as a test for the delete an account function and then go from there.
I haven’t researched the Auth0 or Mailchimp calls, but this should just be a 1 or 2 call request, which means the overall effort to get this added to the Nuke function won’t be too bad.
However, much like the counteroffer experience, each of these use cases likely requires a little more than meets the eye. Not enough that scope changes, but enough that it’s important to be flexible and focus on building a scalable solution quickly.
The 3s that I’m estimating for the work this week would have been estimated at 2s last week.
Designer
This week is largely all under the hood. A button is clicked. There’s a confirmation page to confirm the nuke or purge request. And then a logout-nuke page for nuke. The purge request returns to the account page. These are all reused from other pages. Though, I should spend some time finding a funny meme for the logout-nuke page.
I’m scheduling a review of the site with a Designer friend this week to get some feedback. This will be one of the first times in a couple weeks that I’ll be looking at everything like a user. Which means I’ll need to create different user accounts in my local environment that cover different use cases.
Once I get passed these essential features which require more time on the Product / Engineering, the next time I touch this work (post-Beta launch), I expect to do a holistic re-design.
Scrum master
Slow and steady. I built out a backlog of work and planned out the the sprints for the rest of the year.
I only spent about 5% of my time on this (which is about right), so there’s not much more to share.
The scope increase from Product made sense for Engineering since this is pre-Beta and everything that we’re building should be targeted at making the Beta launch a success. But I can tell you since I was there — my product and engineering perspectives fought hard for like 5 minutes and then settled down :)
