One of the most frequently asked questions we get about Differential is; what makes you different? (i.e. there are a bajillion dev shops out there, how do you stand out). Fair question, and I’m glad you asked.

The short answer: we’re built for change.

The Opportunity

The main reason we decided to focus on building a world-class Development Studio is that we saw a massive opportunity to improve the way software development works. How massive? Well, a quick Google search for “how many software projects fail" will reveal some pretty startling estimates/results. It seems that best estimates are that somewhere north of 60% of all software/IT projects fail (which could range from missed timelines and budgets to complete failure).

Whether working on a napkin stage startup or innovation project for the enterprise, there are some pretty common tendencies that I suspect play a role in those poor project outcomes.

1. You think you know exactly what you need to build. In reality, if you haven't spent time talking to customers, you're guessing. Taking this a step further, consider the famous Steve Jobs advice that "customers don't know what they want until they see it." While I think this is generally dangerous advice (most of us desperately need to talk to customers), there is definitely some truth to this. It often takes an involved exercise like "5 Whys" to get to the root of what they really want/need. In other words, not only is software really hard, so is doing real customer validation.

Why is this so important? We’ve heard many partners we work with say things like “the last dev shop I worked with built exactly what I wanted, and it was a great app, but it was the exact wrong thing to build."

2. Budget and expectations are way out of whack

*

I call this the “build a Facebook clone for $50K” misconception

*

Inability to start (relatively) small

-Not testing key assumptions with V1

-Don’t understand the concept of minimum viable product (MVP), even if you think you do

• Starting with the “what” not the “why"
• No real business model
• Belief that when we launch we’ll have a “finished product” that’s bug-free and self-sustaining

The reality of most projects is you’re starting with assumptions about all of the above. The more you do early validation, research, and planning, the closer you should be, but you’ll almost always still be wrong about something. With that being true, the key is designing projects to test, iterate and improve your odds of getting it right.

Built for Change

All of the above led us to create a different way to approach our work. As already stated, inevitably you’ll still be wrong about things, but we’ve seen big improvements in our projects by following this process. Notice the amount of work that is required before we ever write a line of code. Turns out, you can often save a lot of time and money overall by spending more time up front. Doing so also allows for more change, faster.

Discovery

The Discovery Sprint is designed to drive a critical level of clarity and team alignment around the high-level vision for a product. The process kicks off with a facilitator driving a work session that includes a cross-functional team of stakeholders, influencers, and creative thinkers from our collective teams. During this first phase, we’ll start diving into the key pitfalls outlined above and provide several deliverables that will:

• Keep everyone aligned throughout the project
• Allow you to test key early assumptions

Planning During the Planning Sprint, we’ll do a deeper dive into what key features to include (or not include) based on internal and external feedback to the deliverables created from the Discovery Sprint. Deliverables in this phase are designed to:

• Make it clear what the project needs to accomplish long-term (what’s success)
• Provide a clear short-term plan for what’s being built

Design Now it really starts to get fun and become real. In the Design Sprint we create “looks like/feels like” designs and prototypes that will provide a clear vision and visuals. During this phase a lot of thought is being given to the overall user experience design, core user flows, style guide and software architecture.

*Development*Time to bring this product to life! Having laid a strong foundation for development by working together to clarify the product concept, strategy, architecture and design, we’ll be ready to start building working code, and it will go significantly faster (with less re-work) than if we started here.

QA/Testing, Launch and Support These are all different phases that I’m not going to go into detail on (pretty self explanatory), but note that successful projects will have time and budget allowance for all. Know and be prepared for the reality that there will be new issues (bugs, tweaks, changes etc) throughout.

*Measure, Learn, Repeat*Once we have live software working “in the wild”, we’ll be capturing valuable data and feedback that will help inform future product strategy and decision making. Embrace the truth that software is never “done” and successful software products will require ongoing resources.

There's a reason so many companies rely on third-party consultants and development partners to execute complex software projects--it's really hard! But with the right team, process and pre-work (all allowing for iteration/change) you can drastically increase your odds of success.