‍

Have you ever travelled to a foreign country where you speak some of the language, but aren't quite fluent? Though you may be tempted to put your language chops to good use, speaking the country's mother tongue to order your morning café au lait and croissant, chances are it'll take longer to be understood than if you were speaking your first language. Not only that, but there may be room for miscommunication and errors if you're conversing with someone across two different languages.

The same can be said for product and software builds. Too often, teammates, collaborators, and partners may find themselves relying on different methodologies and 'languages' throughout their development cycles. But when it comes to creating startups, digital products, and new technologies, it's critical to get all parties playing from the same handbook and using the same fundamental definitions.

The vast majority of startups today subscribe to a process called the Lean Startup methodology. By definition, the Lean Startup methodology is a process of starting a company or product that favours experimentation and iteration over traditional upfront business planning. The idea here is to shorten development cycles by adopting a combination of business-hypothesis-driven experimentation, iterative product releases, and validated learning. Chances are you've heard of concepts such as "pivoting" and "minimum viable product" — these are all principles of Lean Startup, and they all serve to aid the feedback loop as companies test and improve their business ideas. 

But what happens when teams are not speaking the same fundamental language on how to develop and iterate products? Particularly when product studios are partnering with IT teams who may be stuck using mature systems, methods, and infrastructure, things can go sideways fast.

IT and Lean Startup methodologies don't play well together 

I'm just going to say it: IT professionals are slow to join the Lean Startup revolution. We've seen this time and time again at POWER SHIFTER, where a company's technical teams come from the IT world and are stuck in their ways when it comes to approaching software design and development.

The irony here is that these IT teams are often seeking the very benefits that Lean Startup methods allow. They want a successful product, and they want to launch it fast. And then out of pure habit, they sink time into massive requirements gathering, documentation, and estimating the cost of each product feature — before there's even a product to speak of. 

While IT teams may employ Agile techniques within their workflows and lean on some of its frameworks (such as Scrum or kanban), IT Agile and Lean Startup Agile are not the same thing. I've found that IT’s use of agile still gets stuck in pre-organized stages of software development, using Agile to reach a predetermined destination. With Lean Startup, that destination is less defined, because experimentation, data, and feedback may take you down a different, more valuable course. 

For the past 10+ years, our clients have been enterprise intrapreneurs and CEOs of startups that use or convert to the Startup methodology once engaging with our team — and for good reason. At the heart, Lean Startup and IT processes are mutually exclusive, and only one will provide continuous value to your customers.

Lean Startup 

• Establishes a minimum viable product (MVP) and iterates
• Favours a culture of experimentation 
• Initial launch typically requires less budget and development time, as focus is only on critical key features 
• Dev team continuously validates approach through a Build-Measure-Learn methodology and pivots as needed

Traditional IT 

• Relies on upfront, long-term, and detailed business planning 
• Sacrifices experimentation in favour of risk-aversion
• Requires substantial upfront budget and development time 
• Dev team works more rigidly against a predetermined plan (2-5 years) and desired outcome 

"Lean Startup" understands that your next product launch is your most important

At the heart of Lean Startup methodology is the idea that iteration and new feature development is what's going to make your product most successful. You don't need to have everything sorted out on day one — but you do need to have a team ready to experiment, test, and adjust based on the results.

Successful digital products should be built to change rapidly based on user-feedback and testing. While the dream of launching an instantly successful product may be alluring, it's just that — a dream. The products users love most are those that started as MVPs with passionate user bases. Rather than planning for a perfect launch, you should be figuring out how to grow a user base that is keen to provide continuous feedback on your imperfect product as you hone and grow alongside them.

Dropbox is a great example of this. At its onset, the company originally provided a short video description of their Dropbox product, explaining the concept and soliciting feedback: what would early adopters want to see from Dropbox? Would other tech users benefit from or be interested in the product? 

The demo predated an official product launch, and had the added benefit of sending thousands of people to the Dropbox website to sign up for the beta waiting list. Even their CEO was surprised: rather than impress users with a suite of product features, he simply had to spark their intrigue with a solid concept. 

Given Dropbox's success today, this example is an excellent testament to the fact that a minimum-viable-product can be even more minimal than we think. Whereas traditional IT processes would have entrepreneurs mapping out a five year plan, Dropbox was able to drum up interest (and eventual success) with simply an idea — the tech equivalent of sprawling a novel on a napkin — and go from there.

With speed, agility, and feedback cycles, development teams can keep adding desired features and improvements to meet the needs of their user bases. After all, your digital products — including your websites — are never "complete", because user needs are never stagnant. As your users' expectations change, so should you. 

Shifting the emphasis away from the initial launch — and instead to the weeks and months that follow — will ensure you're paying attention to those needs and acting accordingly. Lean Startup understands that your products are only as good as your next launch, and there's always a next launch on the horizon.

Getting IT teams up to speed 

When IT teams fail to employ this mentality, instead regarding their software development as working toward a one-and-done initial launch, they're putting their own success at risk. I've found this to be especially prevalent when launching websites; traditional IT teams can fail to realize the full potential of their websites as digital products. What's lost is the opportunity to improve their websites, web applications, and other software through a commitment to testing, learning and iterating. This doesn't have to mean you're in a constant state of development — but it should mean you have the framework in place to learn from your users so you can constantly deliver value. 

If you're looking to transition your team from one way of developing to another, we can help. Either way, we can talk about this stuff all day — get in touch.