A post I wrote on Medium about building a culture that encourages success outside of work:
I suppose I should look back fondly on account wins, project launches, and sound financials. I probably won’t though. What continues to bring me the most joy is seeing my staff achieve things in their field that aren’t sponsored (or directed) by ResIM.
Full post here: Creating the freedom to achieve — What I Learned Building… — Medium.
Good examples of branded mobile applications are few and far between. If you work for a major brand and are considering a branded mobile application (specifically branded utility), please remember this:
People will not download your app unless it provides value not available from competing or replacement products. People will definitely not download your app simply because your brand is attached to it.
App stores are self-contained marketplaces where success is defined by what people are saying about the features, functionality, performance, experience, and value offered by the products available within. Brand equity is almost never part of the formula for success and sometimes contributes to harsh criticism when the perceived value of a brand isn’t upheld in the applications it delivers.
On the broader web, applications sink or swim based on reviews, blog posts, and traction gained via social media. While it may be easier for larger brands to get an initial boost in terms of publicity, the strength of the magnifying glass used to review and dissect the app is inherently increased. It’s like being able to jump into the pool quickly only to sink just as fast.
Having worked with both start-ups and large brands in this space I have a recommendation for the latter:
Approach the development of your branded application as if it were a start-up and imagine the success of your business as being directly tied to the success of the application. If you can’t put this kind of emphasis on the project it isn’t worth undertaking.
Ignore the perceived value of your brand and focus on the value you’re going to provide in terms of functionality. Applying your brand to an icon and interface doesn’t matter if you can’t offer differentiation or an improvement on what exists. Leveraging existing communication channels is advantageous but not when the message can’t stand on it’s own.
This mindset is something that should be ingrained in the project philosophy from the very start. The mobile application landscape pays little service to existing brand equity when the value and experience provided by the application falls short.
The solution, therefore, seems simple:
Make sure the value and experience provided by your application are enough to ensure success in a world where legacy brand power is irrelevant.
We recently launched what is perhaps the largest web project we’ve ever had the pleasure of producing. I use the word pleasure because that’s exactly what it was.
With most year-long, complex, and highly visible projects there exists numerous opportunities for the emergence of negative friction. Friction is typically good for a project because it creates important and meaningful dialogue around a critical component. On the other hand, an abundance of friction on a project with many moving parts and several key stakeholders can introduce a level of risk that exposes the success of the process to vulnerability.
The project in question certainly had friction; but only the kind that resulted in the betterment of both the process and the end result.
I suppose this is due in part to how the friction was handled but I was left with the feeling that some other, critical element was at play. After speaking with those working on the project it became pretty clear what facilitated success in this case:
Respect.
Shrinking budgets, tight timelines, and technical challenges pale in comparison to working in a relationship where respect is neither given nor earned.
Giving respect.
It was clear from the outset that our client had a high level of respect for the value we ultimately brought to the project. As opposed to being given the wheel and asked to drive our role had more to do with drawing the map and picking the best route; a route we had to justify with research and professional opinion.
In turn, we had to respect the inner-workings and constraints of a large, public institution. We had to respect a well-defined schedule while understanding that what we were building had to address the needs of a target audience consisting of nearly every member of the general public. We had to respect the opinions and diverse backgrounds of a project committee of 25.
Earning respect.
Starting a project with a high level of respect is easy; continuously earning that respect through all phases is difficult. Our client earned respect by challenging our recommendations. We earned respect by meeting these challenges head-on and by backing our recommendations with research as opposed to stubbornly sticking to something we ‘thought’ was right.
We earned respect by meeting deadline after deadline. Our client earned respect by properly preparing us for each deadline and internally managing a demanding schedule.
I guess it’s obvious that mutual respect is crucial to the success of any relationship; I’ve just never thought specifically about how to earn in and how to give it in the context of the projects I work on every day.
So, to Alex and the entire team at the Middlesex-London Health Unit, thank you for creating an environment of mutual respect. It was this environment that allowed everyone to succeed and that made our largest project one of the smoothest we’ve ever been part of.
To avoid a shitty, late-winter drive I decided to shorten my trip today in favour of an attempt at productivity in a cafe.
Perhaps worse than the weather is the sad reality that I left my earbuds at home. Not a big deal, usually. Except today, when it’s actually a sad reality.
You see, I’m sitting across from two individuals engaged in a very audible conversation. I know more about them than I should, including the occupation of one of the conversationalists as a health coach. I’m interested in health and fitness so immediately glanced up to assess the source of the admission.
I was disheartened, although not surprised, when my eyes and ears agreed that the self-professed health coach was overweight. Advice about health is still being given as I type this. Advice from someone who appears to be better at giving it than taking it.
Maybe I’m wrong here, and I obviously don’t know the whole story, but something about this scenario unsettles me.
I wouldn’t teach people how to play the piano if the only song I knew was chopsticks.
I wouldn’t teach people how to cook if my signature dish (and the extent of my culinary experience) was KD.
I would feel uncomfortable taking money from people if I couldn’t back-up my advice with both failures and successes in a personal context.
Our ability to provide value in the form of professional education should start by learning ourselves but the curriculum we choose to deliver must be based on experience. The experience of trial isn’t enough, though. Trial without success is indicative of an educator who has failed the most important task…..being a successful student first.
Earlier today I had the privilege of giving a presentation on mobile application development planning at a digital marketing conference in London, ON.
I’ve noticed that many brands and businesses have thrown planning (and sometimes common sense) to the wind when it comes to launching, or thinking about launching, a mobile application. While I’m an advocate of moving quickly and iterating post-launch, I also understand the need to think things through.
If you’re thinking about building a mobile application it might be worth considering the following steps:
Answer this question: ‘Are we building this application for ourselves or for our customers?’
If your response is anything other than ‘for our customers’ it’s time to rethink launching a publicly-available mobile application. Do not pass go. Do not collect $200.00
List all the features.
This step is necessary if you know you can provide value but aren’t really sure of the features you’ll use to do it. Start with a blank page/whiteboard/screen and list everything you think your app could do. You’ll come up some good ideas and some not-so-good ideas. Take your time here and make the list as large as you can.
Narrow your feature-set and draft an application definition statement.
The feature brainstorm should leave you with a couple of clear themes or related features that could be packaged as a focused app. As mentioned in the iOS Human Interface Guidelines, your application definition statement should describe the following:
Find a replacement.
You may want to have a quick look at replacement apps if you’ve come to the conclusion that you should build a to-do app. There are tons. It doesn’t make sense to compete in a class where you can’t offer any strong, differentiating features.
Analyze your competition from a strengths and weaknesses perspective. Try really hard to render your idea irrelevant.
Filter your feature-set through your user profile.
Congratulations, you’ve made it far enough to compare your proposed value proposition to the needs, habits, and characteristics of your customers. Specifically, take a look at what you perceive to be most important to them. If you have the budget I recommend extending this step to include primary research in the form of an audience study or survey.
Any features that aren’t important to your users should be removed.
Go.
At the conclusion of the previous step you should have a refined feature set and a clear application definition statement. Take this and start working with your design and development team to make it happen. Don’t wait any longer.