When Running Fast Gets You to the Wrong Finish Line
When building something, speed is only one part of the equation.
In my last job, we worked on a mobile product aimed at enterprise customers. In a year of planning, sprinting, and building, we must have changed directions (tangentially) more than 4 times. Why is that a big deal? That gets expensive pretty quickly — in sunken costs such as salaries and lost opportunities.
Is this a failure on my part, as the Product Manager, that we spent 1 year building as fast as we could, only to change every so often? Our CEO told me this was just part of the learning process of building a product. While I’m thankful for his understanding , I think this was my fault, and it could have been avoided.
Our company needed to launch the product, and some hot leads started to turn cold, because we were taking a while get the product ready to support our first live client. Naturally, my response was to go faster.
My Hurdle
It was my first time working in the enterprise tech field. I came from games and read a lot about lean methodology, but for B2C or B2B (smaller business) types of companies. In enterprise, things are not as simple as build-ship-learn. Here are some examples why:
- Enterprise clients won’t mind being the first adopters, but there is a minimum amount of polish needed for your product to work.
- Security is a big thing — most enterprises comply with global standards, and those mean very specific ways of building your product and operating it.
In short, it’s trickier to do lean in the enterprise setting (for more on this, I suggest this book, Lean B2B by Etiénne Garbugli). It’s not as fast to get insights that will lead you to Product-Market fit. Even if you interview 100 mid-managers or staff-level users, they won’t necessarily get to use your product unless their C-level bosses approve it. And once you get to the top, things get more relational than functional.
An efficient way of getting into the minds of the top-level people is to get into meetings with them. Then you start to see patterns in their concerns, apprehensions, and pain points. The thing is, their time is expensive. They won’t just let someone take 30 minutes of their time to show them a product that’s in progress, or to ‘pick their brain’, unless that person is your uncle or mother.
Our First Client: HR
The app was first meant as a human resource (HR) automation and company communication tool — to replace intranet systems everywhere and make it more modern by appearing on smartphones. As we went along and interviewed a few companies, we learned their pain points and started to realise that we were opening a can of worms: HR processes differ greatly among companies. Some companies have 10 approvals per document, some have 40 documents, some have 3 approvals that need actual signatures from 3 different people, with 3 days leeway.
The closest lead we had then was a company that was hoping we would customise the platform only for them. While it got annoying for us in the product team, we also realised that their mindset was such, because HR is something very close to a company’s identity. It’s the most internal thing to a company you can think of, next to finance. “Things must be customisable, because our company is unique.” That’s why SAP, Oracle, and WorkDay are still in business.
HR also included all sorts of things that our potential clients all got excited about: onboarding, hiring, company events scheduling and RSVP-ing, among a few of the ideas passed around. HR is about people, after all, and people are different. One client even mentioned an exchange market for its employees to sell off their own 2nd hand items — a great idea, because they have thousands of employees across the country.
We were biting off more than we could chew. We just didn’t have an app that could be capable of that kind of flexibility. We quickly (or so I’d like to think) saw a new pattern emerge: communication was a problem in all these huge corporations.
Uncovering a New Issue
The Philippines is an archipelago: 3 major island groups, with more than 7,000 islands. Companies set up shop in those islands here and there. The traditional ways of communicating were getting either wasteful, expensive, ineffective, or all of the above.
We decided to push back on the HR features, and we focused on the communications aspect of the product. Communication teams were a different beast. Their jobs were to make things interesting, or else they’d be ignored. Who did we start to sell to? We started selling to CEOs, VPs of Communications instead. Their use cases were very different, but more generic.
Another painful lesson was also how we presented the app: our initial design was very bleak, spartan, and plain. We wanted to focus on the functionality. But as we kept getting feedback from corporations (remember what I said about polish?) who wanted to change the UI, we decided to allow them to customise it according to our specifications.
Our focus switched from automation to making notifications stickier, faster, more attractive, and more engaging.
We also learned that some companies didn’t want to just let any announcements through; some wanted to have a layer of approval. A trivial thing to add, but with a backlog longer than a legal contract, and with a team as small as the baristas at one shift at a Starbucks store, trivial was really “a month or so”. We just didn’t have the time for all sorts of things.
Marathon or Sprint?
That process took about a year. A year of thrashing, throwing away some work, and changing purposes once in a while. We even used sprints, to manage our weekly workload and make sure we accomplished things each week.
It was both challenging and frustrating, because aside from thrashing, we were also operating with as much speed as Sonic the Hedgehog could. We tried to get features done, to minimal spec, working across the API layer, Android app, iOS app and web administrator app in a month.
I now realised, I was doing my best to get the product done, I wasn’t doing my best to get the right product done.
What Did I Learn from Wanting to Build Too Fast?
First, before incurring costs, don’t commit any development resources to it. While lean in B2B is different from B2C, you can get away without making an app for the first few months.
I’d let people use a prototype — from what we learned, if you make well-designed hi-definition mockups and prototype them, no one will actually realise your app is not coded yet. I learned that no one really goes to a meeting to burn what you have to show them.
Second, I’d definitely spend more time going out and showing the idea to people. As informal as it may be, and even if it’s not to VPs or CEOs, I would have shown it to more mature people in the industry. Even experienced middle managers will have something good to say about the pain point you’re trying to solve. At the very least, you can get the pain point locked down, and worry about the relational stuff later (or let your sales team figure it out).
Third, the foundations for the app could have been done in the first six months — like modules or frameworks that will be used — technology stack, Login, Notifications, Style guides, etc. That way, when building time comes, the team doesn’t have to build the 4th and 5th floors while building the stairs and scaffolding.
Ultimately, I think blind love for speed was what led me to making the mistake. Speed of wanting to get a minimum viable product (MVP) out. Speed of building the actual app. Speed of reacting to changes.
Speed isn’t bad per se, but I recall a story about a guy who had so much speed, his biggest breakthrough was when he learned to stop. He scored when he did.
