This post is part of Lob’s series of interviews with developers, technical strategists, and business leaders who are innovating, solving problems, and building tools for the fast-evolving world of operational APIs. Each post shares actionable tips to apply to your own projects, products, marketing campaigns, and logistical operations. Sign up for our blog newsletter and we'll deliver these insights directly to your inbox!
The more things change, the more they stay the same. We sat down with Laura Klein, principal at Users Know, to discuss her decades of experience in design and running product teams.
Laura: I started a million years ago as a research associate at a tech think tank, of all places. Since it was the 90s, and the web was just taking off, I learned to program. I got a job doing front end engineering at a couple of startups and went through a couple of acquisitions. I started to realize that what I really liked about building stuff was deciding what to build to make people’s lives better.
Luckily, right around the 2000 tech bust, some friends of mine who were very early in the interaction design space had started a fabulous boutique design consultancy called Sliced Bread Design. They brought me on to do research, which I knew about from my earliest days, and prototyping, which I could do as a front end engineer. They taught me the middle bit - the actual user experience design - and the rest is history.
Well, it’s history until about 2007, when I joined a startup called IMVU as a combined engineer/designer/researcher. Some of you may recognize IMVU as the first “Lean Startup”. I was lucky enough to have Eric Ries as the VP of Engineering. That meant that I learned all about metrics, a/b testing, and using analytics to improve product decisions.
Those are the events really ended up shaping the type of designer and product manager that I am today.
Laura: Well, there was at least one company where the core functionality had so much technical debt that we literally couldn’t make any changes to the most important parts of the code without causing massive crashes and outages. The reason it was so catastrophic was that we desperately needed to improve certain core metrics, but there was no way to do that, because we could only sort of tinker around the edges of the product. We eventually rewrote it completely, which, of course, took forever and caused a long period of stagnation.
The company managed to survive, but many in the same situation don’t. It’s why I’m so militant as a head of product to address some technical debt in every sprint and to build time into the schedule for smart refactoring. Sure, when a startup is fighting for survival, it sometimes has to take on some debt. I get that. But most of the time “tech debt,” especially at large companies or companies with significant revenue, really means “writing shitty code because the PM has unrealistic deadlines.”
At the other extreme, I worked with a tiny startup that was fighting for its life. Unfortunately, the CTO was a bit of a perfectionist who cared deeply about “cool” experiences. We ended up redesigning the front end of the product three times, and ended up with a design that, unfortunately, destroyed our SEO, which would have been the key way for us to drive a ton of traffic without having to pay for it. That company had a very cool interface with a few customers who loved the product, but they didn’t make it, in the end.
One team paid a lot of lip service to test driven development, but we ended up with specific recurring bugs. It turned out that they were writing lots of unit tests, but no integration tests or end to end tests. So, their entire test suite could pass while customers couldn’t even log into the product. And it happened over and over, which meant that development was incredibly slow, and new functionality was tough to build, because they constantly had to rebuild the old functionality.
I still have nightmares about integrating with enormous legacy systems after an acquisition.
Laura: Look, there’s a reason why Galileo didn’t come up with a rocket that could fly to the moon. He had a rough enough time trying to get people to believe that the earth rotated around the sun. If we don’t learn from the successes and failures of people who came before us, we have to create everything from first principles. Ultimately we'd never get past banging a couple of rocks together.
We all screw up. I do all the time. The trick is to keep making new mistakes, learning from them, and hopefully passing that learning on to somebody else so they can screw up in some new way that will move the whole field forward a tiny bit more.
That said, external factors change all the time. Something that was a mistake 10 years ago might be a great idea these days. Don’t just say, “Oh, so and so tried that and it didn’t work, so we should do it differently”. Look at what failed, and understand why it failed. If the underlying reasons for failure are different, it might be time to try it again.
Laura: I wish more systems talked to each other in the B2B world. I’ve been spending a lot of time looking at very large companies. Unfortunately, a lot of them are still on big, monolithic systems with no external APIs and no ability to integrate. They tend to add functionality to their giant, walled fortresses by acquiring startups rather than by letting other companies integrate.
As for systems that have to interact with each other.... I run into this a lot as people cobble together a bunch of external services to create a product. Think Intercom to chat with your end users, oAuth to let users log in easily, Angular as a framework, Launch Darkly to create feature flags, Google Analytics to track behavior, etc.
I happen to really like all of those products. They’re fantastic. My team didn’t have to write a feature flagging system, because Launch Darkly did it better than we would have. On the other hand, I hated upgrading to Angular 4 because a bunch of stuff wasn’t backward compatible.
Whenever you use external frameworks, you get a ton of functionality for a fraction of the cost and time it would take you to implement it. You also get the predictable downsides when things change or get shut down, or somebody else’s bugs affect your customers. The upside benefits are real, but the downside risks can be pretty bad.
Laura: Everything I know about UX gets talked about in my podcast, What is Wrong with UX. Everything I know about building products, I wrote about in my books, Build Better Products (Rosenfeld Media ‘16) and UX for Lean Startups (O’Reilly Media ‘13).
A great interface is vital to a successful product, but it can't come at the cost of mounting technical debt. We agree with Laura on this point! When we built our API, we thought about the experience of our users: developers. We created clear, legible wrappers and pre-built libraries because that's how people actually build products.
.png)
.png)
.png)