A Bad Product Decision

I often wonder if I should have been fired for it

I find that so little is shared by product managers about their failures, which sucks for newbies because it perpetuates the illusion that all these other PMs execute flawlessly, when in fact most are making mistakes all the time.

This is a story about a really bad product decision I made early on in my career as PM at FreshBooks.

It isn’t about an epic company failure, like the un-relatable biographies of famous founders, rather it’s a “run of the mill” screw up on a product. My career survived it, but the experience taught me to be more aware of my assumptions, and how you can still be wrong even when you’re doing the right things.

My other motivation for writing this post comes from feedback on my previous ones. I’ve been humbled by all the people that have reached out letting me know how those articles have helped them be better PMs, but it’s made me aware I could be misleading some into believing there is a checklist to accomplish and then BAM you’re a good PM.

Knowing good PM theory is easy, but applying that knowledge with persistence, discipline, and humility is the hard part.

Setting the context

FreshBooks is an accounting product for small, service-based businesses. Its users are agencies, lawyers, landscapers, etc. — think business owners who invoice their customers for their time and need to track expenses. We’ll call these users “Owners” for the rest of this post.

FreshBooks’ vision at the time was a world where Owners didn’t need to know accounting to run their businesses [paraphrased].

For the product team, this meant that if we could distill “accounting” down to simple concepts that Owners already knew (like sending an invoice) and did all the complicated financial stuff in the background, we would be solving a big problem by enabling them to focus on growing their businesses —and not on book-keeping.

The problem

Despite all the benefits that FreshBooks gave them, Owners were still responsible for submitting their taxes to the government at least once a year. Since most Owners didn’t have a financial background, this usually meant hiring an accountant at the end of the year to help them complete and file those taxes.

The problem for Owners was that nearly all accountants used Quickbooks, and FreshBooks didn’t have an integration because our data models were incompatible.

The solution was journal entries. Think of journal entries as the universal language for accounting. Our team’s job was to translate FreshBooks’ data into journal entries, and then make them easily shareable so accountants could import FreshBooks data into Quickbooks and use it.

Customer validation

We spent months translating our data model into journal entries, which was complicated because we had to apply specific accounting principles to every type of FreshBooks transaction. I happened to be a CPA from a previous life, so naturally I ended up being the accounting authority on the team.

In parallel with the build, we spent a lot of time validating our work with both Owners and Accountants.

With Owners, we validated the user experience of exporting journal entries and sharing them with their accountants. We learnt very quickly that explaining journal entries to the average Owner was like explaining code to a non-developer.

Because of this, we decided to obfuscate the whole concept of journal entries from Owners and just handle them in the background. Owners could continue to simply snap pictures of receipts and send invoices like they always have, and journal entries would magically appear when they were needed.

With Accountants, we validated the accounting principles being applied to each FreshBooks transaction. I must have spoken on the phone with at least one accountant every day for months as one by one we went through something like the following:

Still makes me cringe slightly.

Like every product team in the build phase, we made hundreds of small decisions along the way: some as simple as naming types of transactions, to more complicated decisions like how our support team would solve user issues without needing to get their own accounting degrees.

Then one day, a seemingly mundane decision needed to be made: what date should we use when we create a journal entry?

I ended up making the wrong one, and it was the downfall of the project.

The decision

“Brandon, we need to choose which date to use when we save each journal entry... should we:
1. Use the date that the Owner manually inputs on the expense, invoice, etc. or
2. Use the date that the Owner actually creates the transaction in the app?”
- Engineer on the team

I’m going to get into the details in this next section because it’s important to understand the story.

Dates in accounting are very important for taxes because they can determine if something ‘counts’ or not for that tax year, regardless of when you file them to the government. A simple example is that an expense created on Dec 31st, 2016 would be claimable on your 2016 taxes, but if it was made on January 1st, 2017 you’d have to wait until the following year to claim it. This can have a huge financial impact on the business owner.

The complexity of choosing which dates to use arose because FreshBooks let Owners edit dates at any time. After noodling on it for a while, we realized that option 1 (the Owner inputted date) could lead to accidental tax fraud. Here’s the scenario:

We’ve submitted the same expense in both 2015 and 2016. This is really bad, and technically fraud.

Realizing this decision could have big ramifications, I focused on speaking to accountants — over 30 of them — about this exact scenario. Overwhelmingly, they stressed the importance of not enabling Owners to accidentally double claim any expenses, especially since most of them weren’t financially savvy.

These conversations with accountants quickly led us to give up on option 1. Instead, we shifted gears to focused on option 2 — using the date the transaction was recorded.

This was an intuitively simpler approach. Owners would just go about their year capturing expenses, receiving payments, etc. and we would just use whatever date it was when they created those transactions in the app as the date for the journal entry. Owners didn’t need to learn about the impact their dates would have on journal entries- it would just work.

Replaying the second part of the fraud scenario with this new paradigm:

At the time, this felt like a big win. We’d be able to keep Owners out of trouble without requiring us to teach them any accounting. We made the call to go with option 2, and moved on to make the next hundred decisions.

By December — a month before most Owners would need them — we were ready, and did a beta launch of journal entries to 2% of users. Feedback was great and the journal entires were importing without problems.

Ship it.

In reality the screw up was very quiet.

Why that decision was a mistake

Can you see it? If you can, Shopify is hiring.

One more piece of context: For the vast majority of owners, the reporting period for a tax year lines up with the calendar year (Jan to Dec), so 2016 taxes include any transactions that happen between Jan 2016 and Dec 2016.

The tax submission deadline, however, is usually in June of the following year, which in this example means that Owners would actually start sharing journal entries with their accountants sometime after January 2017.

From the viewpoint of an Owner

This fact alone was not a problem for us, because it didn’t matter when an Owner exported their entries, as the data in the export would respect whatever date range the Owner selected (e.g. “select all 2016 transactions”).

But it was this exporting behaviour coupled with a bad assumption we had made about Owners, that led to our downfall.

The bad assumption we made was that:

Owners record transactions in the app as they occur throughout the year.

The reality is that most Owners, like most people, procrastinate and don’t actually record transactions in the app until they have towhich is when they need to work with accountants to file taxes… which is the following year.

The combination of this bad assumption + the exporting behaviour of Owners + the decision we made to go with option 2 basically made the feature useless for most Owners.

It meant that when a procrastinating Owner starts adding their 2016 transactions early in 2017, all the transactions they added are actually considered part of 2017, and their 2016 journal entry export is blank.

Absolute. 100%. Disaster.

The aftermath

Only the ~25% of FreshBooks users who diligently recorded their transactions throughout the year were able to make use of the journal entry feature. For the rest, it was simply another year of manually working with their accountants to make sense of FreshBooks reports.

Here’s the kicker: because we launched the product in January, it wasn’t until 6 months later in June that we even heard that this was an issue! During that time, we had a launch party, celebrated growing numbers of journal entry exports being sent, and lavished in lots of Owner feedback that sending journal entries “…was so easy, thanks!” (they didn’t realize the data was useless because the export was basically accounting hieroglyphics). Our team even moved on to another project.

Thankfully, once we started hearing this feedback, another team took up the call and ended up quickly fixing the feature later that year to use the date that the Owner inputs (option 1). It was unfortunate that Owners still had the risk of double claiming expenses, but this is by far the lessor of two evils. Since that change, journal entries in FreshBooks have actually been useful to Owners.

Lessons

We didn’t lose customers because of this feature sucking, but my decision ended up wasting months of hard work from an entire team.

Luckily I skirted wrath, and our team ended up shipping one of the most impactful products for FreshBooks the following year. As a PM, making that bad decision taught me some hard lessons that I’ve internalized today:

  1. Recognize the impact your decisions make, no matter how small they may seem at the time. Your decisions as a PM are magnified through the efforts of an entire team and a product with scale. Stay on your toes, and always sweat the details.
  2. Think deeply about all the assumptions your decisions are built on. The toughest assumptions to spot are those that are so ingrained in your company that most people have forgotten they are even assumptions. A close second are those hidden in personal biases we’re not even aware of.
  3. Customer research and validation is critical, but it can’t always make decisions for you. In this story, all signals were positive, but we still shipped the wrong product in the end. Your customers can’t tell you what to build, because they only see the parts of the product they interact with, and not the entire system the product is built upon.

I hope this story soothes some of the imposter syndrome most PMs face everyday as teams continuously look to us to “make the call”. This job is one of quick, high-risk decision making with limitless responsibility for those decisions.

Fuck-ups will happen. You won’t be perfect. But it doesn’t mean you can’t be a great PM.