When I received the final design spec to build the internal portal for a large pharmaceutical company, I knew something was wrong.
The design spec was 1,000 pages long, and it took the team 2 years to create, one year more than they planned for. It had every feature request imaginable in it. Since the original project scope was fixed for 3 years, this only gave us (engineering team) one year to create it. Two years to design and one year to build a product isn’t an ideal situation.

Agile Product Development: Build An Amazing Product in 2020

When I received the final design spec to build the internal portal for a large pharmaceutical company, I knew something was wrong.

The design spec was 1,000 pages long, and it took the team 2 years to create, one year more than they planned for. It had every feature request imaginable in it. Since the original project scope was fixed for 3 years, this only gave us (engineering team) one year to create it. Two years to design and one year to build a product isn’t an ideal situation.

Try to build it exactly the way it was designed. Work overtime, hire more people, and do a rush job to make everyone happy. Ultimately miss our deadline anyway because it isn’t even close to being feasible.

We could come back to leadership with reality: We couldn’t build this in a year. Not only that, even if we could, it wouldn’t make sense.

We chose option 2, and the business team resisted as much as they could. In their minds, everything was critical, nothing could be cut. Through several important “reality check” meetings, we ended up getting our way.

The result: We cut 80% of scope. Yes, 80%. It turns out the critical features they wouldn’t remove weren’t actually that critical at all. We built it within a year, and although it was a successful roll-out in the end, the way this project was run from day one left a sour taste in everyone’s mouth.

I learned several key things from this project:

If engineering, DevOps, design, and business teams aren’t one unit, then everyone is wasting their time. It makes large projects almost impossible.

Keeping engineers coding and not waiting should be a higher priority. On top of the impossible timeline, we were working with siloed teams. When we needed a simple change from the UX team, we'd get it back in two weeks. What are we supposed to do in the meantime?

For the next 10 years, I’ve spent every waking moment helping organizations (large and small) 

bring Agile product development to their organization

. And my goal with this guide is to give you a better idea of how enterprises can adopt an Agile mentality when it comes to building and deploying products.

I’ve had the lucky opportunity to be part of building many digital products from the ground up through my enterprise consulting career and my experience as a CTO for two successful startups, and now my digital product agency, Foxbox Digital.

I’ve been able to help Fortune 100 clients, including Pfizer, USPS, and Morgan Stanley build and scale enterprise apps using Agile and by defining strong product strategies. As the CTO for several startups, I led the technology and product teams to scale to hundreds of thousands of users and tens of millions of dollars in revenue.

The secret? It all started with a strong digital product strategy. I’m going to share my thoughts on how to create a digital product strategy in 2019 and include little tidbits, like the story above, on how I failed and also how I was able to make better product decisions, consistently.

I also want to preface this guide with the obvious: “Startups often get it wrong.” So, blindly telling enterprise companies to do it the startup way isn’t sage advice. The goal of this guide is to help educate you on the successes and failures of startups, and how to get your products to market faster.

At a previous startup I was part of, we followed the Lean Startup methodology by the book. We got out of the office and spoke to customers face to face, and asked them what they wanted.

We got validation of the product every step of the way. Everyone loved it. We launched with a lot of fanfare. We were published on all the major tech blogs like TechCrunch, Mashable, and Venturebeat.

The users came to download our free product. By all measures, it was a successful launch. We did the math and free wasn’t going to pay the bills.

We made an educated decision to make it a paid-only app and completely removed the free version. We warmed our customers up for the transition. It wasn’t a surprise by any means. They knew the free version wasn’t going to last.

We figured since so many people—during our customer interviews—said yes to the “Would you pay for this?” question, that switching to the paid version when available will be a no brainer. Then it became obvious. Users never signed up for the paid version, even the customers that told us directly they would. Our product did everything they asked it to do.

Either they were liars, or we did everything wrong. As you might have guessed, we did everything wrong.

The purpose of this guide is to tell you what my previous startup did wrong, what we would do differently, and how to create an effective digital product strategy in 2019 so you can avoid the simple mistakes.

To start, I think it’s important to understand what separates a good product from a great one. Some differentiators I’ve picked up over the years are simple to understand, and some are nuanced.

The goal is always to build an amazing product, not just a good enough product.

If there was one term that irked me to no end when working in enterprise was “This is good enough.”

Good enough used to be sufficient. Now, good enough means a loss of revenue, lost market share, and any other business metrics you can think of. Don’t set the expectation that just because you work for a big company that good enough is okay.

Here is a simple framework to determine the difference between good and great products.

Great products solve problems in a way that’s intuitive, brings you joy, and strikes other positive emotional response when using it.

Here are a few examples of great products that come to mind:

Additionally, Here are more attributes I’ve seen from great products.

Growth Marketing is built into a product, it’s not an afterthought.

Meaning, the product grows from word of mouth, or a network effect, from purposeful features built into the product to make it grow.

Slack (invite your team, it makes perfect sense), Hotmail (check out hotmail signature).

A quick side note and a word of caution: I’ve personally seen how products went viral because of these built-in growth features, but then users churned really quickly after engaging with the product. So, yes, growth built into a product is great, but to keep up that momentum, the product must focus on the core use cases and solve a real problem.

The product was built around one or two core use cases. It doesn’t try to be everything for everyone. It does one or two things exceptionally well for a defined type of person.

Big vision with small iterative steps is the core of building disruptive products.

Uber, Airbnb, Instagram, and WhatsApp all had bigger-than-life visions. They had big, hairy, audacious goals (BHAG). But, they all started extremely focused to prove product/market fit, and then scaled to their huge goals.

This type of thinking and execution model is the core of Agile.

tools hanging in a workshop

Practical tips on how to make Agile work in the enterprise.

A pivot for a startup would be considered a massive shift for an enterprise company. Too many pivots and you will pivot yourself out of a job fairly quickly.

So, here are some practical tips I believe enterprises can implement to be more Agile.

Small cross-functional teams is the answer to many enterprise product problems.

When I did waterfall projects at enterprise companies, each role had its own departments: Software Engineering, UX, DevOps, QA, and the business stakeholders.

Engineering was on its own. Design and UX only got involved when it was their “turn.” DevOps was separated from everyone and, of course, the business and leadership teams were not integrated at all.

So what happened was that simple design to development tasks took forever, and were often wrong. What took three months in the enterprise can take two weeks in Agile. So, when we engage with clients, the first thing we do is figure out how the project team can be a true cross-functional team.

It’s when you bring all project roles together onto one team to build a product. You have Software Engineers, a UX Designer, QA Tester, and potentially a DevOps Engineer, led by a Project Manager, together on the same team. The entire value of creating a cross-functional Agile team is speed-to-delivery.

For example, when a Developer for any of our 

 needs a design change, they can ask the UX Designer at the next morning’s standup and get it fixed much quicker than waiting after the designer has moved on to something else.

How large should a cross-functional agile team be?

According to Amazon, no larger than you can feed with two pizzas. So, around 8 people max. Why? Any larger and you start dealing with people management issues. Standups turn into long, drawn-out sitdown meetings. Your agile team should be anywhere between 4-8 people. Of course, you can share some of these roles across multiple projects.

Since this involves people, it can become challenging, but feel free to 

 directly and I can give you tips on how to make this happen within your organization.

Yes, the MVP is still a thing (but not what you think it is).

Some people think of a Minimal Viable Product (MVP) as super cheap and quick—like invest $20k and see if it works. If you do that, you're probably missing the mark, and then what you've created isn't a true test of your idea. It has to be viable, meaning it has to actually solve the problem you're setting out to solve.

 Product (although we didn’t invent that term). I’ve also seen the term Minimum Marketable Product which I think is clever.

The MVP has the core functionality that solves the major pain point and nothing else. It still has a polished UX and on-boarding. It’s a subset of an overall feature that delivers value when released independently. .That’s important. However, any "nice to haves" or complementary features not related to the core solve are tabled for a future release. You build in increments and each phase should be lovable, not broken or half-working.

Think of it this way: If you set out to build a car to get people from here to there, you don't start by building a wheel. That doesn't get you where you need to go. You could start by building a bike. From there you could build a motorcycle, then finally a car.

MVPs are often very inefficient on the backoffice—do everything manually. 

. MVPs are focused—they solve a problem with a small, focused feature set. Cut the fat.

UX and user onboarding are essential to an MVP. If your product is hard to use and people can't figure it out, your MVP isn't effectively testing your product idea. It never had a chance.

How to choose between budget, time, and scope.

You’ve probably heard of the “budget, time, scope, and quality—Pick 3” saying.

With Agile, there are multiple levers you can pull, but you can't pull them all. What's fixed and what can give? Budget, time, scope, and quality. 

I can’t stress this enough. Every enterprise project I’ve been a part of could have been improved with a reduction of scope.

Requirements always change. When this happens, your project goes way over budget and you blow past the deadline. Get your product out there, listen for feedback, adjust accordingly. With short 1-4 week sprints, you can make changes quickly, which means you’ll learn and innovate faster. A fast feedback loop is the most important thing you should nail down.

pencil and ruler on a blueprint

How to scope product development in the enterprise the Agile way.

I opened this guide with a story about how we had a 1,000 page spec with every imaginable feature request possible. Of course, every feature was “critical” to the business. Or at least, that’s what they first thought.

We were able to scope down to 20% of the original request to deliver on time. In Agile, product development doesn’t happen like that. Engineers, designers, and business are all in the same room.

How to build the right features every time.

“Can you add a feature dedicated to showing users a calendar of relevant events in their area personalized to their location?”

As a digital agency, we get requests like this all the time. Our philosophy is “Sure, but why? What will this feature accomplish? Will it get you closer to your goal? What is the business case behind building it? Is it worth spending time and effort on this feature as opposed to other core features?”

Everyone wants to talk about the solution and the “killer” features. That's the “fun part." I feel that entrepreneurs who just go out and build a bunch of things without a clear purpose or objective are just having fun. They love the lifestyle and idea of starting a company.

But, the real question we want to ask should be: 

Is this the right feature to build at the right time?

Here are 5 steps you should follow when building out features:

Problems > Features. Always. Don’t get caught up in the sexy features and your new ideas. Growth happens when your product has a crystal clear view of the problem you are solving.

You THINK you’re solving a problem, but 9/10 times your attention is towards what you’re building and not what you’re supposed to be solving.

So, when scoping your features, ask the team if you’re scoping nice-to-have features or if the features tie back to solving problems.

STEP 2: Identify your customer with clarity.

If you can't clearly describe your customer, how are you going to solve problems for them? Do this by creating User Personas. Who are all the types of users who will interact with your product? This includes Internal and external users.

STEP 3: Ask how this product/feature will benefit your business, and most importantly, your customer/user.

You would be surprised how many companies want to build something based off a competitor or because they believe they need it, without a clear understanding of the benefit.

How exactly will this product or feature benefit your business or your customers/users?

, a ridesharing company, could have been just another rideshare clone of Uber. But they attacked a very specific market—commuters in NYC. New York City commuters wanted a more efficient way to get to work than public transit, but couldn't splurge on a private ride every day.

They were willing to walk to a designated pickup spot (that's an assumption too!) in exchange for a lower fare and a faster ride. Via limited the service to just Midtown Manhattan at the start.

They were so successful that now Uber has copied Via's model and sets designated pickup and drop off spots to make rideshares more efficient.

Write these assumptions down at the start of the project, then keep them in mind when planning your User Stories (what we’re building). When we launch your product, we’ll be careful to measure user engagement and impact of business metrics to either validate or invalidate your assumptions.

Let’s use a meal-kit delivery service as an example for our assumptions:

enterprise

1 post tagged with “enterprise”

The Definitive Guide to Agile Product Development for the Enterprise: How to Build an Amazing Product in 2020