The Definitive Guide to Agile Product Development for the Enterprise: How to 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.

So, we had two choices:

1. 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.
2. 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:

1. There has to be a better way to do this.
2. If engineering, DevOps, design, and business teams aren’t one unit, then everyone is wasting their time. It makes large projects almost impossible.
3. 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?
4. There has to be a better way to do this.

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.

Why listen to me?

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.

Yes, even startups get Agile wrong.

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.

Which reminds me of a story.

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.

1. Good products solve problems.
2. 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.

1. Growth Marketing is built into a product, it’s not an afterthought.
   1. Meaning, the product grows from word of mouth, or a network effect, from purposeful features built into the product to make it grow.
   2. Slack (invite your team, it makes perfect sense), Hotmail (check out hotmail signature).
   3. 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.
2. 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.

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.

What exactly is a 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 React Native development projects 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 reach out to me 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.

We actually define MVP as Minimum Loveable 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. That's how Instacart got started. 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. The answer should always be scope. Reduce scope and launch on time.

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.

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.

Here’s how we do it:

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:

STEP 1: Identify problems, not 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.

Here’s a good question to ask: How exactly will this product or feature benefit your business or your customers/users?

Example:

Via, 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.

STEP 4: Document assumptions early.

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:

• People want to cook gourmet meals at home if they don't have to shop for the ingredients.
• People want meals picked out for them.
• People are willing to pay extra for each meal if we do the shopping for them.

These are solid assumptions to help you create an effective product/business.

STEP 5: Be objective.

When we start on new projects, we push for clarity. Do we know exactly what you want to build? Do we know why you’re building this? And when we get into features, we take it a step further by writing down the User Stories.

Bad Objective: Create push notifications for marketing purposes.

Why? This is a feature, not an objective. We start the planning process by stating your goals/objectives, then we can create a project plan that prioritizes the features that have the biggest impact towards achieving your goals.

Better Objective: As the marketing team, I want to increase daily retention by sending our users push notifications.**

MUCH BETTER. This gives us better, specific guidance on how we should implement push notifications. This is the difference between sending out a push notification once a month, to sending out daily personalized push notifications with a clear focus on increasing daily retention.

Use this as a template sentence structure: As a (type of user) I want to (achieve some goal) so that (some reason). I prefer to write these on notecards.

STEP 6: Listen for patterns of feedback.

It’s easy to react to someone’s request and start the build process, and that hardly ever works. Instead, listen for patterns. If you hear the same thing from 10 users, listen to what they’re trying to tell you.

How to prevent constantly changing product direction every other week using the Inbox System.

I’m no stranger to product direction changing almost daily. Agile is built for flexibility of scope, meaning you don’t have to have one year of scope locked in before you can build anything. You build, test, and learn.

However, a CEO I worked with in the past took Agile product pivots a bit too literal. He would send me new feature requests almost every day, slightly changing product direction each time. And every feature was more important than the previous.

My job as the CTO was to build the product, not run the company. So, I wasn’t in a position to say no to these new features, even when I was only halfway done with the features we started weeks prior. I actually did care about what he wanted to build, I just didn’t think many of these features were the right decision. But, who was I to say no?

So, I thought of something to help me alleviate this pain.

After a few panic attacks, I created what I called the Inbox System. This was a place in our project management board where I collected all of his ideas. It gave me a chance to say, “Great idea! Let’s discuss later.” He knows that his idea isn’t lost, and I don’t feel the pressure to act immediately.

In the next sprint planning meeting, we would go through all of these ideas, weigh them against all of the other issues (i.e. features, bugs, cards) in the backlog, and prioritize the things that will have the biggest impact towards achieving our company’s objectives.

It was a small tweak, but it made a substantial impact. I was heard. He was heard. And together, we made the best decision for the product and company.

The Inbox System aims to solve the problem of changing the plan mid-sprint. slow down, plan things. You don't want a reactionary dev team, where the latest idea from the stakeholder is implemented over things that have been planned for weeks.

I operate under one model: Every feature can certainly not be a winner.

This isn’t 3rd grade where everyone gets a participation trophy and feels like a winner at the end of the soccer match.

Implement the wrong feature, and it can significantly impact the trajectory and traction of your app. Not just because users don’t like it, but for simply how much effort and time it took to complete.

As a Product Manager or Project Manager, you’ll get a lot of input from your stakeholders. For us, it’s our clients. For businesses, it could be your CEO or boss. It used to give me anxiety when I heard all these lofty feature requests: I felt like I needed to implement all of the ideas my CEO threw at me over email, text, or Slack.

Many ideas sound amazing in the moment, but the luster wears off quickly. If it’s still a great idea during the next sprint planning, then consider implementing it. If not, discard it—that’s okay to do, it’s part of innovation. All ideas can’t be winners!

How to get your team to ask better questions.

Remember how I began this article with how we failed to build a business around a product that we thought was validated by customers?

Our customers said the magic words: “Yes, I would pay for this.” But, when the product finally went live, they never did. Not even tried it out for a month and cancelled type of thing. They never put up the money at the level we thought they would.

It turns out that asking someone “Would you pay for this in the future?” is very different than asking them “Will you give me $10 from your wallet right now?” Especially as a large company, you need to do your customer development just like the startups do.

We did achieve growth, and some users loved us, but ultimately, we had a churn issue and the product didn't quite cut it. I believe it all came down to the questions we asked during the product validation phase.

Here are some mistakes we made and what you can learn from them.

Avoid hypothetical questions.

We asked too many hypothetical questions. Instead of asking “Would you pay?” the question should have been “Give us your payment information right now, and we’ll charge your card as soon as we launch.”

Ask questions based on real experiences:

• Tell me about the last time you faced this problem.
• Why was it so difficult?
• How do you solve for it?
• What’s wrong with that solution?

Here’s a great video that talks about the right questions to ask:

This gets your potential customer talking about real life experiences, pain, and solutions. It’s grounded in reality, and therefore you can trust the information you hear. Make sure you’re trying to solve a real problem that actually needs to be solved.

Ask how painful their problems are using a simple 1-10 scale.

We would ask questions like “Do you go to meetings and come unprepared? How do you solve for that?” Then we would go back and create a solution to that. We never asked how painful it was for them.

What’s worked really well for me after that experience was asking potential users how painful the problem was on a scale of 1-10. Walk them through a real world experience and ask how painful it is for them.

One person experiencing a problem isn’t enough.

We got so excited when someone validated our solution that we never really considered how many people experienced the problem. If we got together and asked ourselves these three questions, we would be okay:

1. How painful is this problem? (pain meter)
2. How many people have this same exact problem?
3. Can we actually solve this problem?

Agile Execution Tips

The fundamentals of effective sprint planning.

When it comes to sprint planning, there is good and there is bad. I’ve narrowed down the best fundamentals down to these 7.

• Identify: What are we trying to achieve this sprint? Good sprint goals are measurable, and you can answer the question “Did we achieve our sprint planning goal?”
  • Terrible example: Build new onboarding - why are we doing that?
  • Better example: Improve on-boarding - great! Let’s make it measurable.
  • Best example: Increase completed sign-ups by 15%
• Look at your backlog of user stories and identify the things that will help you achieve the goal of the sprint.
  • You’ll want some bigger, and some smaller issues.
  • It’s a good idea to fix bugs early so you don’t accrue too much tech debt.
  • Early-on in the project you’ll want to work on the bigger, riskier things. Save the safe predictable stuff for the end.
• The Product Manager, Project Manager, and key stakeholders draft the upcoming sprint with what they’d like to accomplish. It’s a good idea to only detail out the user stories when you actually plan to do them, because you’ll never build many of your user stories. That’s okay, it’s normal. Agile is about being efficient and not overplanning.
• The conversations you have in the sprint meetings are the most critical aspect of Agile planning. Clear, direct conversations about the complexity about a piece of work or even a conversation about if there is capacity to add a stretch goal are what makes Agile tick.
• Bring in your development team to estimate each story in relative terms. People are naturally really bad at estimating to precision, especially in software, but we’re actually really good at estimating relatively (this looks roughly the same size as that), and a collective group is even better at it. I prefer the bucket system of estimating using small/medium/large.
  • Bucket System
  • Small - 1 unitless “point”
  • Medium - 3 points
  • Large - 5 points (anything bigger, try to break it up)
  • Examples:
  • Bad example: This requirement will take 2 weeks to deliver.
  • Good example: This requirement is 3 points since it’s similar in size and complexity to a typical medium-sized requirement.
• Collectively agree on how much you can accomplish in your 1-2 week Sprint. The total number of points you achieve each sprint is called your Velocity. At the start of the project, you won’t know what your Velocity is, so you’ll have to guess. As you get into your project, you’ll have a better and better understanding of your velocity, and you’ll be able to estimate the project’s completion with more and more specificity. For this reason, it’s really important that your stakeholders are flexible on scope: You won’t know how much you can actually complete until well into the project!
• Lock your sprint. Once you have your sprint planned, what do you do when a stakeholder asks to add “just one thing” in? Two options:
  • Add to your Inbox and plan it for the next sprint.
  • Something’s gotta give: Ask your stakeholder to remove something from the sprint of similar size. This way, you make your stakeholders happy, they are in control, and you aren’t overwhelming your development team.

Repeat this process every 1-2 weeks.

Agile execution tips to abide by.

1. Design the core product UX/mockups upfront to about the 80% mark. This allows the client, or even users, to see how the product will look and make changes before development starts. You can continue designing during development: new features, additional product states, and refining existing features.
2. Plan the upcoming sprint in absolute detail (and only the upcoming sprint). Why just the upcoming sprint? Because requirements change and we don’t want to waste time planning things we may not even build.
3. Collect user feedback. What are your users saying? Are they using your app as you expected them to? Are they validating your business assumptions? Be willing to change course or alter your plan based on what you're seeing from your user behavior. If you build in a vacuum and never let users see it until launch, you’re going to miss the mark. The key here is to get early feedback on your product. You want to ensure the product that you’re building is actually solving the problem you’re trying to solve, and doing it in the best way possible.
4. Don’t think your first version is going to solve all of your users’ problems. Think ahead at least 12 months (to the best of your ability). The best way to do this is to clearly state your high-level objectives and create a rough plan on how to get there. Look into product roadmaps examples to build out your first product roadmap.

A simple framework for making product technology platform decisions.

After you get your core User Story list ready for development, you have to make a decision on how you’re going to build it.

The good news is that you have plenty of viable options. The bad news is you have plenty of viable options. One Google search will get you more confused than when you started.

Here are two core questions I ask when figuring out the proper platform to build on:

Where are your users when they encounter the problem for which you’re solving?

Believe it or not, in 2019, not everything has to be a mobile app. Context is extremely important. If it’s for business purposes, then your users are probably sitting at their desks when they’d need to use your product. In that case, a mobile app doesn’t make sense. Build a web app.

If you have a mobile workforce, for example, sales people on the go (outside sales), or delivery people in trucks, then a mobile app could make sense.

How often does this problem happen?

This is such an overlooked, but obvious question to ask to get more context to the problem you’re trying to solve. If your users are on the go, and need to use your product every day, then a mobile app could be a great solution. If they’ll seldom use it, then a mobile app actually creates friction because they’ll have to install it just to do something once. In that case, create a mobile-responsive web app. It’ll serve your users regardless of which platform they’re on.

Agile works in the enterprise if you follow best practices

We’ve all been part of the half waterfall, half agile type of projects. I think each organization has its own unique way of implementing Agile, and there is definitely no one-size-fits-all situation.

At Foxbox Digital, it’s been our mission since day one to help enterprises build better products and follow better processes and procedures that lead to better products, shipped faster. If you enjoyed this article, and think we can help, please feel free to reach out to me directly on LinkedIn or go to our contact us page to reach out to us.