This post is part of the Our Mistakes series, in which we take a good hard look at things we’ve messed up and log our lessons. Our hope is no one else has to learn these things the hard way.
Adam, Co-CEO, CMO: We built a product we ultimately couldn’t deliver.
Ross, Co-CEO, CPO: Our partner wanted software so flexible it would have limitless functionality: anything a user might want, they’d get. But nothing can be purely flexible. There is an underlying logic that it must follow.
Flexibility is a good thing, until it’s not.
Adam: We were building a marketplace for accountants, tax specialists, and their clients, which are usually businesses, to manage their connections and their projects on one platform.
Ross: But some accountants are also tax specialists, so they play both these roles. And some businesses have more than one name, so they want aliases to appear to different clients. And instead of going through an onboarding form that’ll populate a contract, some businesses already had contracts they just wanted to scan in.
Every single corner case we ran into, the first instinct was to customize it, rather than say here are the rules of the platform and everyone needs to play by these rules. What we could have said was, We’re all on the same playground here.
Flexibility is a buzzword that everyone should use really carefully
Ross: They’d asked us to deliver a scalable and flexible system.
We were thinking, Of course we can build something flexible. We’re dynamic. Flexible means you can change data or change templates in real time to build things on the fly — super flexible! The client was thinking, I want it to be flexible enough to skip steps, to do whatever I want.
Our logic was: We have a set of forms that are flexible — you can add and remove things — and that data was stored in a database. From there, we generated a contract. And that step was flexible too — there are multiple contracts, different templates.
And even then, the client asked, Users don’t want to enter data into form. They just want to upload the contract without the form. Why can we not do that? Why is your system not flexible?
By flexible they meant, I want to skip step one of the logic. That’s a different kind of flexibility. Even though the question is simple — Can I just upload a contract? — to implement that, we have to change the database structure. We can do it, but it changes the whole architecture of the platform.
So, instead we hardcoded features for every flow and, at the end of the day, it’s so flexible, it’s not flexible: If you are this user type, you won’t see this field. Or, you’ll have different values for that field. If you change something, it’ll break something because there’s another rule somewhere that only applies to some other edge case.
Ultimately, we said, Yeah we can do it. We can make it that way and that way, build this monster code that’s almost impossible to maintain, that’s such a complex thing no one knows how it works.
Adam: It’s flexible, but not simple. There are three different onboarding processes, and tons of edge cases.
We had to stop saying yes
Adam: It’s amazing how when you release a product, one voice can completely derail you. There can be 1,000 people who log in, 995 of them have an amazing first experience. You can look at analytics and see they did x, y, z. You hear from 5 of them, Oh it’d be nice to have yada yada — and the first response is generally an overreaction: a lot of ASAP messaging. Hey, we need to do this ASAP! That’s our mistake.
Something like 90% of the users were the traditional model, but those corner cases had sway. They asked for a lot of features. As they started asking for more and more, I was really aware that we said a bunch of yeses. I knew the code and the logic was getting messy.
Ross: When we were saying yes, it’s not that we were simply saying yes. We tried to fight it, but we were not trying hard. It went like this: We tried to explain it. No, they still want it… Maybe we should try something else? No, we still want it.
And, that means saying no more often
Adam: At some point, we said, That stops now. We’ve made too many mistakes. We need to build V2 — simplify a lot of things, do things properly without all these edge cases.
Ross: It’s very hard to say no when the person is paying you, saying this is really needed, this is ASAP. We want to say yes. Every single product you release, the customers are going to ask you for new things.
There are areas where we could have said no. We do need to serve the client, but our 80/20 yes to no ratio should have been closer to 50/50.
We need to set clear expectations on the impact our decisions are having. Use no as an explanation — flash forward to the future, show the consequences: No, we’re not going to do that because…
Or, We shouldn’t do that, but we understand that we need to, and understand that it will have an impact.
Or, We are making this decision together, we know it has to be done.
Our POV: Define everything
Adam: So, define everything — literally create a glossary. We needed to know what flexibility means and have the same definition of that. The glossary gives us a way to say, When we’re talking about this and that, this is what we mean. If you mean something different, let us know. It’s also a launching point for being able to say no when it needs to be said.
Shared vocabulary and a willingness to say no are both signs of a true and functioning partnership, where the client’s goals are our goals and our success is their success. It’s not someone paying you to say yes, it’s someone partnering with you to find the right answers.
