Screenshot 2013-12-22 at 10.03.45 PM

The Product Canvas: bringing a product vision to mobile app development teams

There is a fundamental difference between web development and mobile app application development that many people don’t think about: when you develop for the web, although you own the intellectual property of that piece of the software, the page or service is available publicly. Therefore, it’s an asset of the web. When you develop an app for a smartphone, regardless of what it does, it is a product that will be owned by the person who decided to download it. So, even though you will keep the intellectual property of the app’s code, the app itself doesn’t belong to you anymore – it belongs to the user. The user will then decide to use it, to keep it, or to delete it. Once an app gets deleted, it’s hardly going to be downloaded again. Think about how many times you did it.

mindset shift between developing for the web and for mobile devices, UX stands for User Experience

The smartphone home screen has become the “most expensive real estate” in our personal digital lives. A good example of this was when Apple launched the newsstand app and prevented users to delete it or even hide it inside a folder. This was so annoying that a user found a bug in the OS that could be explored if you were fast enough to tuck the app inside a folder immediately after you created it.

So, it is safe to say that when developing a mobile app, a team must have a product mindset and therefore it should revisit its software development process. Developers typically look at projects delivered on schedule, on budget and with quality as successful. When developing mobile apps, though, this is not enough. If you think of apps as products that need to add value to their target users while delivering great user experiences, there’s much more you’ve got to pay attention to. And the only way to do it is to bring the “product perspective” to development teams. We, as an agile end-to-end software development shop, created a visual tool to fill in this gap.

Agile software development is great to foster constant communication between business stakeholders and the development team. In the SCRUM framework, it is common that at least the Scrum Master – or team leader – speaks with the Product Owner (the person on the client side who represents the business vision) on a daily basis. Developers are constantly encouraged to engage with business representatives to learn about the details of the features – or what we call stories – to be developed. While this constant communication greatly promotes focus and keeps the pace of productivity (blocks are identified and removed quickly), it usually ignores the whole picture by decomposing the product in small chunks of functionality that will be developed independently by different people. It’s not very uncommon that some developers end up working within a very limited part of the product and do not have a sense of the whole product and business objectives. An important question then stands out: if they don’t see the whole picture, how can they effectively contribute to the overall user experience?

So, how can we change this status quo? How can we incentivize software engineers and other team members to keep in mind that we are building a product with specific goals towards a user audience and the business behind the project? And, how can we make sure all people involved on the client side, not only the PO, can quickly validate if our view of the product is right? While there might be many answers to these questions, we decided to look for the simplest visual solution, like the kanbans that we use on a daily basis.

(real kanban wall as seen at Ci&T Software, Brazil DC)

I recently read about Forrester’s POST method and it was stuck in the back of my mind for weeks before I realized it could offer an interesting way to organize the product development process and goals in a visual way. The product canvas was born.

As in the kanbans, we use post-its to write on the product canvas and a template is shown below:

We have four big set of questions represented by each of the four quadrants and they need to be answered in this order:

1. People: The audience of your app. You should put yourself in their shoes and try to answer to the post-it questions while identifying personas, contexts and expectations of the people using the app. There should be as many post-its as needed to draw a good picture of the app audience;
2. Objectives: The goals of the business building the app. Put yourself in your client shoes and try to answer the questions;
3. Strategy: Things you have to take care of in order to increase the chances of meeting business objectives while making users happy;
4. Technology: Among all platforms and technical approaches, what is the best fit for the three quadrants we just discussed?

So, in a nutshell, the product canvas preaches that technology should be the last thing you think about when developing a highly engaging mobile app. It greatly facilitates the conversation between developers, designers and the business and provides valuable insight for technological decisions that otherwise would be made in a techno-centric fashion. User-centric development with business in mind is the way to go.

For technology, a mobile development shop or mobile studio should have a portfolio of approaches that can be leveraged in each specific situation. It all depends on what you want to maximize: user experience, agility, reach, savings, etc. We at the Ci&T mobile studio are currently focused on three main pillars:

* Native: iOS, Android, Blackberry and now Windows Phone. Although you have to program in each OS-specific language for each platform, this is the best way to go if your goal is to provide the best possible user experience for a device.

* Hybrid: The idea is that you will be able to use HTML, CSS and Javascript as universal languages to build apps for multiple platforms. It’s much easier to find people fluent in these languages than Objective C and Java. The hybrid approach will allow you to access low level features of the phones through specific APIs and will generate a native app that can be deployed to the specific app stores. We’ve done some development using Appcelerator’s Titanium (a true native code generator), but our preferred hybrid approach is Phonegap (a browser-powered app engine) with native implementation of extensions whenever needed.

* HTML5:  a standard that is being pushed forward by big leaders in the market and that allows developers to build rich applications to run within compatible browsers. Your apps can potentially run in any currently available smartphones with small adjustments due to different form factors. The downside is the limitations of what can be done with HTML5 and apps won’t be able to access hardware-specific features of the phones.

We have been successfully using the product canvas at Ci&T’s mobile studio in all mobile application engagements for the past 6 months. We begin building it during the pre-sales phase, and as soon as the project starts, we add a big print of it right next to our kanbans. The product canvas is updated throughout the project lifecycle so that everyone is kept on the same page every time a product decision is made. It proved to be very useful for us to understand product goals in a very concise and direct way and have every stakeholder understand what the product is about.

The feedback we have been receiving from our clients is astounding. They say that we “seem to be asking the right questions at the right time”, which is a very good side effect of the main goal of bringing our development teams a clear perspective of client’s vision about the product we are building.

If you are interested in learning more about the product canvas, I prepared this slideshare presentation for a hands on approach:

Comments via Google+