Learning Agile Methodology the Hard Way

In the last three years as a product manager, I’ve run several startup teams using Agile methodologies. There’s a ton of us who can do that in the tech industry, of course, but I think my experience is a bit more unusual than others’. That’s because up until three years ago, I had never taken a course or even read a book on Agile.

So how did I get from there to here? Through pain and suffering!

I’m not totally kidding.

Creating products with Agile is hard because it forces you to validate them through customer feedback, to build a workable answer in less than two to three weeks, and to execute as quickly as possible at all organizational levels. Agile is a process that helps customers get the product they need, not what they think they want, and is used in software development, hardware manufacturing, or other industries that delivers goods or services.

Yet because it’s a very specific process, it takes some time to get used to the idea that your assumptions are wrong.

In this way, learning Agile reminds me of watching my three-year old build a bridge out of magnetic blocks. He usually has no idea what he’s doing, he’s not an architect, and he doesn’t know how to do complex engineering calculations. Yet, he managed to build a perfectly good bridge that sustained the weight of his toy cars in about five minutes. Instead of spending lots of time planning and thinking about getting everything right, he just started building. He would put some blocks together and then they’d collapse. He would pick them right up and try again, slightly adjusting their position. After several rounds of trial and error, he had a bridge that worked. Could it be improved? Of course. But he solved the immediate problem quickly.

Similarly, you need to be able to test theories and ideas with customers, get feedback and pivot towards a solution. You can’t spend all that time designing the perfect solution. It’s not unlike the following cartoon I think best exemplifies Agile:

Source: Crisp/Henrik Kniberg

The first step in a successful Agile product launch is customer validation — figuring out if there are enough people willing to pay for your product or service. After you’ve validated your idea, your engineers can help you build your minimal viable product (MVP). This is then followed by improvements, optimizations, and addition of features that occur over time.

What’s the biggest benefit of using Agile? You’re not stuck building a complex monster of a project for six months before you can launch and start generating revenue.

If you can improve your educational process into Agile, I recommend that you do it. Read everything you can and ask managers. And I also suggest that you learn from the pitfalls I fell into as I learned the methodology the hard way.  

How Product Management Happened to Me

I actually fell into product management like a boy into a well. I never set out to be one.

It happened when I was working at a mid-sized tech company trying to sell multiple products to one market. Complex and expensive, the products required pre-sales engineers like myself to onboard customers. After unexpected buyouts and layoffs to product management, I was left as the only one who understood both sales and technical issues. So they naturally named me interim product manager.

Guess what? I had no idea what I was doing. Basically, I put together a plan of everything I thought the product should do or be, and just assumed engineers would build it. Over the course of five years, sales for the products plummeted. I never spent any time with customers trying to learn their pain points or what problems they needed solving.  

The other products weren’t doing much better, either. Product managers made poorly-researched assumptions that led to poorly-made feature requests. If customer A needed to do X, they’d expend as much resources as possible to build that one feature for that one customer, and then move on to the next one.

It wasn’t a total failure. In fact, we had hundreds of paying customers all over the world. Eventually, the business was sold and we moved on. But the growth was so miniscule the last years compared to what it could’ve been if we’d really understood our customer’s needs. If we had focused on customers instead of our own assumptions, I think our company would have been worth much more.

Fortunately, I met some new friends at this company in the last few years before being sold, one of which advocated for this weird thing called “Agile.” At first, I thought it just meant being fast, but what I didn’t appreciate then was that it wasn’t just a new style of programming, but a philosophy that an entire company can embrace to bring about positive results.

One day six months after the acquisition, I was asked to join a startup. As the only person who understood their app’s technical details and prospective customers, I found myself running product. But I started to make the same mistakes again. I assumed that since I knew the tech and customers well, I’d know the type of product they’d need. I spent time with customer but our interactions were limited. It was more like me trying to sell an idea instead of learning about the problems. My fatal flaw was assuming I knew what the problem the product was going to solve was.

Fortunately for me, the lead developers on that team were strict adherents to Agile. Once they felt comfortable doing so, they pushed back on my assumptions — big time. At first I was angry. “What do they know?”, I’d say to myself. But my goodness were they right.

They encouraged me to use Agile principles and think in the simplest of terms:

• What is the problem we are trying to solve?
• Why does the customer want this?
• What is one problem we can solve for them?

Instead of trying to make the perfect product with EVERY feature a customer might want, I was encouraged to think about the one feature every customer might want. It sounds obtuse, but in order to succeed, you have to find one problem and solve it simply. Some customers want it to do X, others wish it had Y, but all agree it needs to do Z. I was trying to build X, Y, Z and more. The more the merrier, right? Wrong. The Agile guys taught me otherwise.

Let me give you an example about what we did.

The platform we were building managed a lot of video. We assumed customers didn’t want to interact with the platform or care to see the videos themselves. It was just our naive assumption as we thought we knew what the customer wanted.

But we started to get feedback that customers had different ideas as to how the platform might solve their problems. Mainly, they wanted to see a video file play in the user interface. It took two days combining open-source technology, making decisions about where to store the proxies, and eventually we decided to place a player in the browser to view the proxies. Suddenly we were getting further along with customers, raising more money from investors, and gaining platform awareness.

Eventually we started getting customers who wanted to implement their own technology to create proxies, or already had proxies that they wanted to use instead. In each instance, we improved the platform to accommodate these different use cases.

What if we’d tried to build our own solutions and allowed customers to plug in theirs? We would have taken months to include all of these features and capabilities and gotten zero customers and probably run out of money.  

That was two years ago. Today, that business has grown and I attribute it to our early adherence to Agile.

Since then, I’ve seen amazing problem-solving apps emerge suddenly, engaging customers within three weeks, and making money in under a month. The trick to Agile is to spend time with target customers, be ready to have your assumptions challenged (and maybe destroyed), and to focus on small, simple things.

This is why I love the first picture above. The customer may tell you that what they want is a car, but what they really want is to get from A to B. In two weeks you’ve invented the skateboard, which they will pay you for since it solved their problem (getting from A to B). Two weeks later you’ve announced you’ve invented the bicycle. It will get them from A to B even faster. Finally, they’re driving your cars, having been a paying customer since you launched, and telling all their friends about how great you are.

That is Agile my friends.