Lean product development is possible, also in corporate environment

What’s the purpose of mobile applications? 
Fun? 
Better communication? 
Organising stuff?

Yes, but above all it’s making people’s lives easier. Sometimes it’s by giving users a way to kill boredom, sometimes it’s by making it easier to book a yoga class or communicate without extra charges. But sometimes it’s also about making people’s work easier and more effective.

Today, apps can offer a lot more than fun, supporting the field of healthcare, on-demand services, education, etc. This is why Apple noticed the value of iPad in Business, and turned their eyes on apps that help business and serve people in order to make their work a little easier.

But how to approach projects for corporate partners?

Is it possible to keep the project lean?

At the very beginning, let’s put it clear:

We don’t often work with corporate partners.

Why? Because the way we work isn’t usually easy to implement in corporate conditions. Of course, it’s not impossible to be lean (in the sense of Eric Ries’ “The Lean Startup” book) when creating products for huge companies, but if you work agile, you probably know that daily calls, iterations etc. are usually seen as a waste of time by huge businesses.

What corporate companies are often used to instead, is sending strict specification of a final product to the outsourcing company and waiting for the results. The approach is totally different in case of digital product studio, who is used to sharing their expertise in order to create something valuable for the partner and approaches the product as the entire ecosystem, taking care of strategy planning, development and optimisation, to create something that we, as a team, can be proud of. And for us, this is the core difference that makes us think twice before we decide to start the cooperation with huge businesses.

But there are some exceptions…

Time for a short case study.

Not long ago, we met with an international company that wanted to improve logistics in their production hall. Up to that time, ordering transportation of specific items needed in the production process was arranged by the workers via phone calls. As you can imagine, this wasn’t the most effective way to deal with communication.

In order to make things easier and faster for the company workers, the management came up with the idea of using iPads and beacons. After sharing a general idea of what’s needed, we met and discussed their issue.

During our meeting we not only got to know the problem and the idea of the solution, but we also visited the production hall to better understand what’s really needed. Seeing plans of the hall prior to the meeting was helpful but actually being on place made us realise what should and what doesn’t have to be done to solve the initial problem (and, by the way, it was a great fun to see the production hall!)

After coming back we started with app outline. First users types, crucial steps, then the flow for all users and setting up how the app should look like in the background.

Our brainstorm generated the project’s Q&A:

Do we need routes for transportations? 
No, we’ve seen the hall and we decided to leave the route choice to workers.

Do we need location? 
That can be problematic in this kind of environment.

Do we need beacons to connect with devices so we know if the action is done? 
Maybe, but not necessarily now.

We realised the thing: If we wanted to cover all the things discussed during the meeting, It would give a big, complicated app, that would deal with much more than just improving logistics.

Sure, we could go for it, offer it to the customer, outline the cost and get to work. But again, this is not how we do it.

The application would require the company to buy a lot of devices (with stands, cases, holders), on the stage during which we wouldn’t yet know if the app actually improves people’s work.

At this point, we decided to design a simple version of the app: 
a) solving the initial problem 
b) fast to create 
c) enabling us test the solution without investing tons of money.

If it works, we can expand it or change it to fit workers needs better. User testing forever!

We prepared a flow and clickable prototype of the application that we sent to the company. During a short call, we explained our idea of creating a proof of concept that will allow them to test it before spending big budget on it. Something that will be easy to iterate and expand further after we have a proof that the direction is right.

Results?

They loved the idea and our approach!

Conclusions

Working with corporate customers is different from working with startups — usually, the rules and guidelines of a tender make it almost impossible to implement agile methodology. But being flexible with our approach, often results in bigger flexibility from our partner’s side.

Finding a middle ground to create a product that impacts people’s lives is worth trying, even when dealing with the corporate structures. The only thing that we should be prejudiced against is prejudice itself.

Read more from Untitled Kingdom:

• How to choose a company for app development?
• Why to develop your fintech solution in Poland
• Why you don’t want freelancers for your product