Versapay: Digital Payments Mobile Strategy

Agile empowers businesses to rapidly identify and respond to new ideas. Living through a pandemic has proved these innovation techniques to be more important than ever. Learn how you can support this vital process.

How You Can Empower Innovation by Becoming an Advocate for Your Agile Development Team

Living through a pandemic has shown us that businesses need to be flexible and resilient to thrive in this new era of business. In a time when so much is uncertain, businesses must be willing and able to constantly adapt to changing circumstances.

Agile provides an execution framework for accomplishing exactly that. By taking people out of their functional silos and placing them in customer-focused multidisciplinary teams, the agile approach allows businesses to rapidly identify and respond to new ideas.

Even those outside of the agile development team have an important role to play in supporting agile at their organization. We will examine how leadership can act as advocates to the agile development team, and therefore empower growth and innovation.

To start, let's review the difference between agile and traditional (waterfall) methodologies for project management.

Waterfall works well for linear projects where the team knows exactly what they need to do to get the job done. The traditional command and control, sequential “do this then that” approach.

On the other hand, agile works well for dynamic projects focused on new ideas and innovation, where multidisciplinary teams uncover unknowns and need to learn and adapt to rapidly changing circumstances to create the best possible outcome.

 It is the practice that enables organizations to act on their new ideas.
- Tim Brown, IDEO CEO

What Makes Agile Adoption So Challenging?

Moving from a more traditional waterfall, command and control approach, to agile isn’t an easy task. The most common reason why agile adoption fails is because company leadership is not fully bought into the process.

Successful agile software development requires an openness to address unknowns via an interactive process of 

 Leadership must understand the importance of innovation as it pertains to company growth, and learn to overcome their fear of change so the business can progress and evolve.

If the organization does not support the team in experimentation, the team will not be empowered to practice true agile.

Empowering Growth and Innovation Through Agile Development

For agile to be truly successful, it is essential that business leaders become agile advocates. This means they are not only bought into the idea that agile will provide better outcomes, but they actively support their team to by paving the way for them to succeed.

Here are ways that business leaders can support their agile development team, and therefore empower growth and innovation.

Recognizing problems help us improve and grow. The best agile teams take failures and turn them into learning experiences and successes.

While “fail fast” is a philosophy commonly associated with agile, what agile really allows teams to do is “learn fast.”

 Without making missteps, the team will not have the opportunity to learn where they can improve.

This can be scary for leaders that are not used to an agile environment. However, when agile teams are able to overcome small failures, they learn how to prevent larger ones in the long run.

Trust the Team to Make Their Own Decisions

Agile teams need the ability to work quickly and address unknowns when they arise. Long bureaucratic approval processes can become significant roadblocks in allowing teams to access the tools that they need to innovate.

In order for teams to capture opportunities, they need to be able to act autonomously.

 This requires full trust from the organization that teams are experts in their own domain. With this trust, teams will be empowered to optimize processes as well as ask for, modify, and use the tools they need to create the best possible work.

Understand the Difference Between Capacity and Throughput

Focusing on throughput means that the emphasis is put on how much a team is producing, and not how much each individual member is working.

By not forcing each team member to constantly perform at their maximum capacity, they have more time available to support each other and solve problems when they arise.

Efficiency is often lost when trying to do too much.

 The most important thing should always be the outcomes the team is delivering as a whole.

Commit to Stability to Achieve Innovation

In order for the team to focus on impact and delivery, the organization should prevent them from experiencing instability or shock. 

Distractions are a threat to the productiveness of the team and can prompt counterproductive coping behaviors and poor decisions.

The organization as a whole needs to be educated on agile so that they also understand when their own actions can be detrimental to company innovation.

Successful agile development is contingent on 

 from all levels of an organization. When an agile team is empowered to explore unknowns, the product becomes more innovative and 

better serves the user and the organization as a whole.

If you want to learn more, here are some helpful resources:

Leading agile transformation: The new capabilities leaders need to build 21st-century organizations

New Requirements For Agile Leadership: How To Lead Differently For Agile Success

To Build an Agile Team, Commit to Organizational Stability

The rapid rate of technological change is forcing enterprises to reinvent themselves and provide more flexible approaches, so agile transformations are key. However, knowing that agile is important is one thing, but the ability to properly implement the main principles, tools, and techniques of agile is another. Let’s explore time-tested agile principles that will help your organization build innovative products that customers love.

How to Nail Agile Collaboration and Build Better Products

Agile, as a modern framework and approach to developing software, has evolved significantly over the last couple of decades. Today, 

 means producing quality software in short, fast increments, also known as continuous delivery.

The rapid rate of technological change is forcing enterprises to reinvent themselves and provide more flexible approaches to addressing the needs of consumers and individual business units. This is precisely why agile adoptions and transformations are key. Business today is different than just three years ago, and organizations must be quick on their feet to keep up with the competition, or they simply won’t survive.

Knowing that agile is important is one thing, but the ability to properly implement the main principles, tools, and techniques of agile is another. Let’s explore several time-tested agile principles that, if properly implemented, will help your organization build innovative products that customers love.

Don’t Move Forward without Total Agile Buy-In

In order for agile to work, everyone in the organization who will make that transition needs to buy in. It’s that simple!

Now, it is obviously difficult to switch a team—especially one used to waterfall approaches—to agile overnight. It doesn’t work that way. However, a good way to onboard agile into an enterprise is to start with one product team and build consensus on the team through meetings, brainstorming sessions, and actual Scrum adoption in order to generate total agile buy-in within that team.

This means bringing all of your team members together—the UX team, the product owners, developers, and IT operations— and getting them out of their silos and introduced to agile.

It’s important to note that the entire organization doesn’t need to be agile to succeed. A prime example is BMW. It's not that you must roll out agile across the entire enterprise to succeed, it's that you need to roll it out within a complete business unit to be successful. While BMW's mechanical engineering side is unchanged, its software development side is totally agile, and they do not function at odds.

When You Know You’ve Nailed Agile Collaboration

There are a number of core principles and qualities that constitute a true agile project.

People over process and features over systems

The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Putting people first means frequent and transparent communication to ensure that customer needs are being met at each stage of the development cycle. If the process or the tools drive development, the team is less responsive to change and less likely to meet those needs.

Within the Agile Manifesto, there are 12 key principles that characterize how agile works. Of those, three focus on the importance of collaboration:

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

In Scrum, we manage change in two-week cycles with whatever is being built set in stone, but what's happening next is constantly in flux until we commit to the work. This is reflected in the second underlying principle of the Agile Manifesto: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."

No system is ever treated statically. In fact, you must work under the assumption that people, markets, demands, and everything related to the development cycle are in constant flux.

Iterative approach to product development and testing

Agile collaboration means that software development takes place in smaller segments, so that feature code is designed, developed, and tested in repeated cycles. This is undertaken through regular team sprints that produce working code, which can be regularly showcased to the customer.

The 10th principle behind the Agile Manifesto says, “Simplicity—the art of maximizing the amount of work not done—is essential.” This is probably the least understood principle but the one with the biggest implications.

The idea here is for development teams to focus on the “why” and then work backward to solve the customer problem. It’s the Pareto Principle, or 80/20 rule, in action: You have to ask yourself what 20% of the effort will yield your team 80% of the results.

There are numerous flavors and approaches to agile and how to structure a team, but one of the most well-known examples is a Scrum team. A Scrum team is a cross-functional group, usually between five and 10 people, who have the skills, talent, and ability to define, build, and test a customer-friendly software solution.

My company has adopted the “Scrumban” methodology, a hybrid of kanban and Scrum, in order to support our needs as an agency and help us succeed in product development. For it to work for us, we use these three roles:

The agile project manager is the facilitator of the agile development team and responsible for helping the team get the resources they need to reach their deliverables on time. This leader protects the team from problems and distractions and works with the product owner to ensure the development process is on track.

In addition to the classic ScrumMaster responsibilities, the agile project manager is involved at least peripherally in the decisions around the product and is empowered to provide lower-level product support, such as clarification on the details, or to make a quick decision on a feature, should the product manager not be available.

The product manager is in many ways the voice of the customer, and is ultimately responsible for the vision and definition of the product. The product manager ensures that the agile team works on the right features at the right time. This individual must liaison closely between the development team and customers to ensure a clear and deep understanding of what product features are needed in the application.

In addition to the classic product owner responsibilities, the product manager also helps the client understand our process and how to be a part of it, so they can take a larger role in development and be more involved with the creation of the product.

The development team is a cross-functional group of members with the skills to build, test, and deliver digital products that customers and stakeholders love. That might include business analysts, user experience designers, developers of all stripes, and more.

The Scrum team is self-organizing and empowered by the organization to manage their own workflows. At the end of the day, it’s not just about coding, but working together to build an innovative product that is successfully tested and deployed.

Avoid These Roadblocks to Agile Collaboration

Many complex factors go into the success of an agile project. There is no magic formula you can point to and say, “This is the solution.” It’s easier to identify the roadblocks to an agile transformation.

With that said, there are many things frequently causing companies to trip over themselves when attempting an agile transformation. Here are my top four roadblocks for agile collaboration that frequently happen.

To work effectively, agile requires total buy-in throughout the organization. We’ve already discussed this point at some length above. But total buy-in also reflects a major cultural shift in the way an organization works, thinks, solves business problems, and delivers solutions.

Agile is a cultural transformation for any organization, and it’s easier if it starts with the executive leadership, but it’s not unheard of for organizations to start a transition to agile within a team and then gain support up the chain.

Developing a product just because it’s cool is not going to drive it through to successful delivery. From its start, an agile project must reflect the organization’s overall mission, vision, values, and goals, and those elements must be reflected in the actual work being done.

If there’s not a continual effort to organize the product roadmap into a series of incremental builds that are prioritized in a strategic manner, then the project will fail.

The success of an agile project really depends on the team’s synergy and their ability to work together proactively with passion to see the project through to completion. Coding skills are important, but they are not everything. It’s a given that your team will have coding and DevOps chops. But onboarding a team of strangers who don’t know the strengths and weaknesses of their colleagues, have never worked in an agile environment, or are stuck in a legacy mindset, are all recipes for disaster.

One of the fastest ways to fail at agile is to take a “mix and match” approach by trying to blend agile with waterfall under the wrong circumstances. It's not a matter of which methodology is better, but rather knowing when and where to use what.

Waterfall makes sense as a methodology in situations where you have a well-defined process to create a product, and you have “known unknowns.” It allows for the process to be optimized based on foreseeable issues, such as in manufacturing.

On the other hand, agile should be used when there is a lot of complexity, you have a lot of “unknown unknowns,” and the issues are not foreseeable. Agile uses the inspect-and-adapt method to account for those unknowns, allowing a team to react quickly and readily to shifts and changes in the marketplace and how the product needs to evolve.

Many enterprises are undertaking massive transformations to deliver faster and keep up with customer demands, but when this fails, it often can be traced to their inability to properly implement agile methodologies. By fostering a collaborative culture, encouraging the principles that support a true agile project, and being aware of the primary roadblocks to agile ways of working, you can set your teams up for success.

Kanban and Scrum are two of the most popular versions of Agile in use today. We have adopted a hybrid of both Kanban and Scrum as a successful framework for product development.

Agile & Scrum: How to Build Better Products, Faster in 2020

 is an iterative approach to software development that builds software incrementally instead of trying to deliver it all at once with an arbitrary deadline (as with traditional “waterfall” approaches).

Agile works by breaking projects down into little bits of functionality, usually called user stories, prioritizing them, and then continuously delivering them in short cycles called Iterations or Sprints. These cycles typically span one to two weeks.

Digital companies today rely on Agile methodologies to stay ahead of their competition and deliver innovative products to market faster than ever. But Agile is not a one-size-fits-all solution. There are various flavors and approaches to Agile transformation.

Kanban and Scrum are two of the most popular versions of Agile in use today. In fact, here at Foxbox Digital, we have adopted a hybrid of both Kanban and Scrum as a successful framework for product development.

In what follows, we’ll highlight the Agile tools, best practices, and methods we’ve successfully adopted to build innovative digital products that customers love.

Scrum and Kanban are two Agile methodologies we use at Foxbox Digital 

when building new products with React Native

The two methods share many similarities but also have some 

Scrum is a lean software development methodology that focuses on just-in-time delivery of functionality and managing the amount of work in progress (WIP). The key to our successful delivery of projects begins with our two-week sprint and proceeds through the full lifecycle of story-telling in a layout, within 

, where we build the user stories, story-point them based on an assigned numbering sequence (consisting of a Fibonacci sequence to estimate the size and complexity of a user story), and prioritize them across a Kanban board.

Two weeks for us seems to be short enough to develop in a very concise and iterative fashion with our features. But it’s also a long enough time to allow the engineers to build something that has real value.

Sprints are more than just cycles of development, we also have several recurring meetings around our two-week sprints. Before a sprint begins, Foxbox will host a Backlog Refinement meeting with the client to ensure designs are reviewed and ready, and we have a clear understanding of the business requirements for each piece of functionality.

Principle #2 — Manage Your Engineers’ Time and Let Them Focus on the Right Tasks

Engineers want to engineer, not sit in meetings all day or debate what feature should be built and when. To improve development velocity, managing your engineers’ time is a critical task. Here’s how we do it:

: The planning call will outline the goals of the sprint and discuss the breakdown of issues within that sprint.

: We queue up issues in order of priority and across a Kanban board. Our planning calls focus on the issues ready to go in “Current.” Any engineer can self-assign themselves an issue in Current, and our general rule of thumb is they work on issues from top to bottom.

: And now we introduce Kanban. We don’t hard-cut everything and say, "Okay, here are the 10 issues we need to do over the next two weeks." We like to ensure the developers know which activities are the most important. There is always an ongoing workflow, where priorities are continually ordered and updated.

Principle #3 — Simple Issues Drive Clarity (Avoid Complexity)

The goal is to drive clarity on what exactly needs to be built and how long it may take. The less confusion the better off everyone will be. To do this, we identify all the issues we’ve queued up and:

During a planning session, our engineers will agree on a level of complexity for each issue. That level of complexity is represented by what we call “story points.” Story points give us a way to track how much effort will be needed to create a feature and generally are not correlated with an estimation of time.

The reason we do not estimate time with story points is for the same reason a salesman cannot give an estimate for how many sales they’ll close in a month, because there are too many variables to account for when estimating.

The reason to use story points is because you can track how many a team does per sprint, and then take an average over a number of sprints to find their “velocity.” Velocity will tell us on average what a team can get done per sprint.

We track our total points for each sprint because having an idea of our historical velocity will give us context for what we can achieve in the current sprint and also manage project deadlines and expectations.

We adopt a Fibonacci sequence for point estimations (1-3-5-8). This is more of a democratic process. The team will typically vote and build consensus around the complexity of an issue.

We use T-shirt sizes, so a 1 is a small issue, 3 is a medium issue, and a 5 is a large issue. A 1 doesn’t necessarily mean 4 hours of work, some projects are much more complex and a 1 can take longer (or it could take less). If an issue is voted as an 8 or larger, that means it's our responsibility as a project manager to break it down into smaller iterative chunks.

Principle #4 — Use Kanban Boards to Harmonize Your Sprints

 goes from right to left, so this represents the flow of development:

Always look top to bottom for priorities.

QA review means it’s done and ready for user testing.

Principle #5 — Create Your User Stories to Answer “Why Are We Building This?”

 are ways to describe features that customers might like to see in their software. A user story describes the type of user, what they want, and why. In other words, user stories are a starting point to a conversation that establishes the real product requirement.

But why can’t we just give a simple statement for what to create instead? Well, here are some examples of why that does not provide the same information and flexibility as a user story.

This statement is too big/vague. It does not provide any information except that a sidebar menu is needed. We should also be answering the following questions:

The sidebar needs to expand over ¼ of the screen, with a quick animation and color change while the sidebar is opening.

While this statement provides more information, it is not valuable. It does not answer key questions and makes critical assumptions that may prove problematic later on. We should be answering the following questions:

Again, who wants this? Who is the target user?

Does the user care that the sidebar expands across ¼ of the screen as opposed to ⅕?

What if ⅓ makes more sense due to what the sidebar is going to contain?

Does the user care about the color change while the sidebar is opening?

User stories are useful exercises. They help ensure you’re writing stories that deliver value (if you can’t achieve a value statement, check if you have a really good user story). The stories remind engineers about “Why are we building this?” If you can’t write it as a good user story, is it ready for development?

For every value statement, we assign it a short title. We use this format for every value statement: As a ___, I want to ___

So, let’s say we wanted to build out the sidebar navigation. One potential value statement would look like this:

Even though this follows the convention for how to write user stories, this does not contain any valuable information. We should be answering the following questions:

What kind of user wants this? Who is doing the action?

What value does opening the sidebar provide?

Why does the user want an easy-to-access menu? Is the current menu hard to access?

Can the user’s issue be solved with an easier solution?

Instead, a better value statement would look like this:

This user story provides an enormous amount of information in a simple statement:

But let’s take this to the next level. Here’s a fully defined value statement:

expand the side navigation and easily find any category

I can order what I need more quickly and not search for it

This user story immediately gives you a wealth of information:

What role the user plays in this app, as well as what role they play more generally, which allows us to better work the feature for them.

The action is paired with what it needs to accomplish and includes what the menu needs to display.

The user’s stake in the feature is also clearly laid out and addresses the pain point it solves.

Each story also contains tasks and acceptance criteria. Tasks typically consist of a checklist filled out by the engineer. These are tactical things that need to be done to complete an issue. Acceptance criteria (also called “business requirements”) are the most important part of the “user issue” phase.

: QA will go through the task checklist themselves and make sure this feature does the following things. It looks something like this:

The sidebar menu needs to expand over ¼ of the screen.

There needs to be UI for placing orders (i.e., the shopping cart icon and text).

There needs to be UI for driverless runners.

Create Your User Stories

Principle #6 — Measure Progress (Sprints, Tracking Velocity, and Burndowns)

It’s important to know how we measure progress. We’re using GitLab to setup sprints, which is how we track our sprints. We will add issues to each sprint and monitor the progress, so you can see the burndown chart for the sprint fix. GitLab serves as a good little analytics tool for tracking your burndown.

 — Shows where you are in a sprint and where you should be. We track points closed for every sprint (i.e. two weeks). Sprint 1: 10 points. Sprint 2: 15 points. Sprint 3: 7 points. By using a rolling average (i.e. right now it is ~10 points), that's what we expect to see in our current sprint. Velocity becomes a lot more valuable after a few sprints by helping us understand what’s working and what’s not, as well as give an estimate for how much work we are on track to complete per sprint and beyond.

 — If tasks don’t get done, they roll over into the next sprint and get reprioritized. But it's very rare if we haven't finished something that I would deprioritize it because it was prioritized for a reason (so we just continue on to the next sprint handling that issue).

Each recurring meeting is an important part of Agile development. While in pure Scrum all meetings are held within a sprint, one of the meetings we do after is called a retrospective, or a “retro.” A retro allows the team to reflect on what we did really well, what we did not do so well, and how we can improve.

It's an internal meeting because we want the team to feel they’re in a safe place to share their thoughts about progress or things that have hindered them. It's kind of a knowledge-sharing session where we talk about process improvements.

Principle #8 — Communicate Early, Often, and Consistently

We send weekly updates to clients, and they can always access us on Slack. We want them to know they can communicate with us directly whenever they need to. We also host a bi-weekly meeting, usually in-person, with the client where we demo our progress and elicit feedback.

Our meetings often turn into a prioritization meeting. We discuss what was done, we show-and-tell features, we have them test live with us, we get some feedback in real-time, and we put together a game plan for future sprints.

In the “old days” of waterfall software development, user features were scoped out upfront, requirements identified, and then everything was handed to engineering teams who would deliver back, after several months, a complete app that everyone was sure the customer would love. But without testing and iterating on feedback during the process, the "finished product" would often land far off the mark.

Nearly all business executives today believe that Agile is critical to business success. If you’re launching a digital product (or considering one) then you won’t want to miss this recent podcast on Enterprise Radio where our CEO Rob Volk discusses why more and more companies are choosing Agile and React Native to build innovative products. 

The Agile and Mobile Revolution with Rob Volk, Founder of Foxbox Digital

In July 2017, Forbes interviewed more than 500 senior executives from around the world, and 92% said they believe organizational agility is critical to business success. If you’re considering a digital product or roadmap, or are just curious about what Agile is and how it helps companies grow, then this podcast is a must-listen.

I sit down with Eric Dye of Enterprise Radio

 to talk about Agile and why more and more companies are adopting this transformative approach to mobile development.

Please listen to the podcast in the link above, and for those that like to browse ahead, check out our show notes.

1:49 — My goal in building Foxbox Digital was to help large companies build with the agility of a startup while using modern development practices.

2:15 — React Native is a really phenomenal cross-platform mobile framework and the reason I like it is because I think it's well-suited to 90% of the apps out there. It's something that gives you the benefits of cross-platform so you have one code base and one team building for both iOS and Android.

3:47 — Typically, the reason companies decide they need Agile is because they’re experiencing some symptoms, such as late project delivery or reliability issues that come up during the integration phase (or worse, when the product has gone live).

4:53 — In order for Agile to work for everyone, the entire organization has to be bought in. This means the UX folks, the product owners, the developers, DevOps, etc. must be brought out of their silos—so everyone is bought into Agile from the start.

5:36 — What doesn’t work with Agile is to just choose one group, say your UX team, to adopt this approach. It must be all or nothing.

6:10 — In order to do real work, you must have an extended period of time of uninterrupted focus. That's when you can really get your “deep work” done—things that matter.

6:40 — So Slack is a perfect avenue for people to interrupt you. It's become part of our culture for people to expect immediate responses. But that's unfair to you because that prevents you from doing actual work.

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.

agile

7 posts tagged with “agile”

How You Can Empower Innovation by Becoming an Advocate for Your Agile Development Team

How to Nail Agile Collaboration and Build Better Products

Agile & Scrum: How to Build Better Products, Faster in 2020

The Agile and Mobile Revolution with Rob Volk, Founder of Foxbox Digital

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

How I Prioritize Product Features From the CEO & Founder

How to Define your Minimum Viable Product (MVP)