Nearly one-in-three software projects are canceled before they are completed and more than half cost at least twice the original estimate, according to the Standish Group. The missed opportunity costs could be immeasurably higher and measured in the trillions of dollars over time.

The outside-in development attempts to solve these problems by keeping the team focused on the people that will ultimately use the product—the stakeholders. By doing so, you reduce the chance of building code or features that aren’t used or miss the point, thereby increasing the odds of success.

In this article, we will take a close look at outside-in development and how to integrate the principles into your organization to deliver valuable products on time and on budget.

Nearly one-in-three software projects are canceled before they are completed and more than half have significant cost overruns.

Focus on Your Stakeholders

Imagine that you’re in a meeting to plan a new product release for an industry-specific analytics solution. Designers want to upgrade libraries to create more beautiful charts; developers want to focus on refactoring some outdated code; and, the product manager wants to see a complex new feature added.

How do you balance these requests with limited time and budget?

Outside-in development involves taking the time to understand your stakeholders. These may be end-users, clients, reseller partners, or even internal users. It’s impossible to prioritize development tasks without first understanding what people will ultimately use the software on a day to day basis.

You must also take the time to understand their goals. While this sounds straightforward, the process is complicated by the fact that goals may vary considerably across a diverse set of stakeholders. You need to find a way to capture these goals and prioritize them in a way that makes sense for your product.

The problem with the hypothetical meeting at the beginning of this section is that everyone was thinking from their own perspective. By thinking through the eyes of a stakeholder, the team can focus on collaborating to meet those goals rather than fighting to include features in the new release.

Lead with Design, Not Code

The best way to understand stakeholders and their goals is to involve them in the development process early on. Of course, most stakeholders don’t know how to code and may have trouble conceptualizing a product that’s described using written or audible words—design captures the experience much better.

[content_upgrade cu_id="5055"]Download our free checklist of conversation strategies to glean real insights from stakeholders. [content_upgrade_button]Download Now [/content_upgrade_button][/content_upgrade]

Google Ventures invented the idea of a Product Design Sprint to increase the odds of making something that’s truly useful to stakeholders. By validating with cheap post-it notes and sketches, you can avoid writing expensive code that must either be refactored or thrown away entirely.

Product design sprints take about five days and involve

1. Understand: What job is the stakeholder hiring the product to accomplish?
2. Diverge: Imagine a wide range of possible solutions to the problem.
3. Converge: Narrow down these solutions and determine how to validate them.
4. Prototype: Build a prototype using tools like Invision or Sketch that stakeholders can use.
5. Test: Interview stakeholders to see if the prototype matches their needs using open-ended questions.

The product design sprint may need to be repeated several times before arriving at the optimal solution. In some cases, the stakeholder may have no clear pain point, the business model may be shaky, or assumptions were proven wrong. In that case, you have avoided the time and money of developing a product!

Let Behavior Drive Your Tests

Most developers are familiar with test-driven development (TDD) as a way to ensure that a product properly functions, but how do you know if an entire feature is properly meeting a business need? Behavior-driven development (BDD) attempts to resolve these goals by putting business goals first.

BDD consists of two main practices:

1. Discovery Workshops: These are short and frequent meetings where business and technical teams gain a common understanding of a user story. Conversations about concrete examples that illustrate business rules and acceptance criteria eliminate the likelihood of misunderstandings before a feature is actually built.
   
   
2. Executable Specifications: Concrete examples are converted into executable specifications using Given-When-Then scenarios. Using Cucumber, JBehave, or other BDD frameworks, these specifications can be automatically run throughout development to get immediate feedback about how much remains to be done and whether a feature meets the actual business requirements.

Executable specifications can be easily integrated into existing continuous integration processes to confirm that everything is functioning properly from a high level. Unit testing and other test-driven development tests can still provide more granular assurances that components are working as expected.

HipTest makes it easy to get started with behavior-driven development by providing a nontechnical interface that supports a common business terminology for everyone on a development team. Business and technical teams can build scenarios using a straightforward user interface and those scenarios can be easily converted into executable specifications using HipTest Publisher.

Business teams can also use HipTest to easily access the entire life of a feature, from creation to the latest release, while accessing living documentation of an application that’s always kept up-to-date with each executable specification. Everyone can always be sure that they’re on the same page.

Getting Started with Outside-In Development

The core idea behind outside-in development is to start with functionality that’s closest to the stakeholder—the user interface. Product design sprints start at that point and behavior-driven development ensures that it remains the key area of focus throughout the development cycle.

[content_upgrade cu_id="5055"]Bonus Content: Don't forget to check out our extra resource on user interview strategies [content_upgrade_button]Download Now [/content_upgrade_button][/content_upgrade]

The beauty of outside-in development is that it’s very flexible. You can start integrating some of the techniques without changing your entire organization overnight. The only prerequisite is that you start involving stakeholders early on in the development process before writing code.

If you’re interested in BDD, sign up for a free HipTest account and learn how easy it is to get everyone on the same page.