shutterstock 224696404 1

The mechanics of MVP software development

MVP software development is a lot like maintaining a prized vehicle. There are teams, processes and procedures that keep the car running smoothly — like an oil change or rotating your tires. Similarly the Agile process keeps MVP app development projects on track.

A window into Agile methodology

Agile development methodology is substantially different from the more sequential waterfall style of project management. Rather than completing project phases in a predefined order like a car on an assembly line, teams using Agile methodology revisit requirements, development and design throughout the course of the project during incremental sprints. At the end of each sprint, a shippable product increment is created.

Using Agile Methodology, every two-weeks teams hold a period of planning, development, progress and review called a sprint. Teams running an Agile process for their MVP software development can inspect and evolve during the course of the project, recalibrating the release, optimizing value and re-steering the course of the project if needed.

Highly Agile organizations met their goals and business intent 75% of the time compared to the 56% who met their goals and intent using another project management methodology or without a structured approach all together.

Assembling iterative, interdependent development teams

Conceptualization and ideation are the initial project stages that ensure Agile product development is well-positioned for success. Collaboration during the course of the project is essential. Thus, choosing the right team can spell the difference between a model project or a mammoth disaster.

Have a clear understanding of your need before you approach a mobile app development company. Know what purpose you want your solution to serve. Determining your users and business needs will help guide initial strategy discussions with the software provider you choose.

If you maintain an ongoing relationship with a mobile software provider and are debating bringing your next project to them, review past results carefully.

Sometimes you just have to cut the cord

Consider this scenario. You released an app or web solution a year or two ago with one partner. Lately, things just haven’t been functioning as they should. How do you know whether you should cut ties and begin work with a new provider or adapt your current solution?

Look for these tell-tale signs your relationship with your current software provider has run its course:

Your software partner isn’t full-service. The inability to reach users on mobile or through a web browser is another flashing red beacon to move on to something new. This is where your users are and want to be. Your solution needs to be available there too.

You’ve excessively customized the white-label solution you first released. This red flag also screams, “Time to build a new product.” If you have needs greater than what a basic solution can provide, it’s time to begin working with a team who can help you realize them.

Your current provider has become notorious for over-extending on projects. When mobile app development companies overextend beyond their capabilities and over promise beyond what they can deliver, there are very real costs associated. The costs beyond just development dollars are important too. What does over-schedule and over-budget delivery mean for businesses? It might mean the launch of a new brand or other internal software is delayed, or the growth of your business is constrained. Worst of all, a competitor may beat you to market.

You feel compelled to review the review. After each sprint review, assess the progress. Ask yourself whether the work completed by your provider matches your expected timeline and budget. If not, be vocal. Your mobile app development partner should be guiding the process, not the other way around. If you’re bringing more ideas and process to the table then they are, there’s a problem.

If you determine it’s necessary to start working with a new partner, ask yourself these questions so you have answers when your new partner asks you.

  • Who are my users?
  • What are their business needs?
  • What value will my app add?
  • What are the high-level features under consideration?

Once you’ve chosen your software provider whether that means sticking with your current provider or finding a new team, the real work can begin.

Understanding MVP software development

Markedly different from its meaning in sports, in web or mobile app software development MVP stands for the Minimum Viable Product. This is the first complete representation of the product with a limited feature set defined during prioritization. The end-result is the leanest first version of the app that satisfies client needs and offers users value.

Defining your MVP and confirming your provider can help you realize it is the second step to running an effective project.

Feature prioritization 1Clarifying your needs and setting your priorities

Your needs and priorities will inform your MVP. The best partners ask about your users and business needs to help you set the requirements of your app and the features you need to achieve the behavior and actions you expect to see. Your partner can play a role many within an internal organization cannot. They can be the “objective mediator” helping to call out value in certain features and point out where costly pitfalls may be lurking.

It’s easy to get side-tracked by priority assignments that are passed “down the food chain” — so to speak. Rather than a VP calling out a feature as a “good idea” and it bubbling to the top due to the social authority associated with the request, you provider can help you weight the benefits or challenges with each internal ask as the project progresses.

The key to a successful project is coming to an understanding with your software provider about what you both expect to see in the final project. The right software development partner should spend a lot of time asking about the features of the project from your users’ perspective.

Sign of success: Your software partner asks questions from the user’s perspective.

Your software development partner should work with you to understand your basic needs, business objectives and goals.

Design software users can’t resist and keep them coming back

A user’s experience accessing software depends on the amount of value they gain from it. At the very beginning of your process, think about what your user needs and expects from your solution. As you work with a software partner to map how users move through your app, portal or website, break their actions into steps. Then create an interface that guides them seamlessly through each. Put yourself in your user’s shoes. The best strategists, designers and developers are empathetic. They adopt their users’ mindset and think about the features and experience that would provide the most value.

Focus on the core

Back to our car analogy, just as an engine powers movement. The list of features you prioritize will guide momentum during the MVP software development process. Without requirement gathering and feature prioritization, the product owner and project manager won’t have enough information to set a team loose designing and developing the project because they won’t have enough information to understand the project cost and time required.

Feature complete 2The race to feature complete

The “race to feature complete” is the risk management and development strategy we use to identify, plan and develop core functionality. Once you’ve worked with a software partner to define your MVP, you’ve identified a given number of features to complete before launch. Let’s say there are 10. Work on those features until they are functional but not polished. Then use your extra time and budget before launch to double back and take higher priority features from “good” to “perfect.”

For example, suppose you’re working on a reader app. You could spend hours finessing the page turn animation. Or, you could code it so it’s workable, and return to polish later.

Don’t get stuck in a continuous loop perpetually fixing and editing one feature. If feature complete isn’t achieved and the app doesn’t launch the component you spent so much time on — won’t matter anyway.

Understand the cost of veering outside scope

Caution: Backtracking, rework and adding additional “bells and whistles” to the first release are key culprits responsible for driving up costs and pushing out your completion timetable. Prioritizing your features is crucial to staying on schedule and on budget. If you are on a tight deadline to complete core functionality, avoid the temptation to backtrack and add more features halfway through. This only serves to divert you from the core capabilities your solution needs to launch. Instead add them to the backlog.

If you do choose to add features to your first iteration or reprioritize functionality, understand the cost.

Don’t let perfection stand between you and working software. There’s always the opportunity to fine-tune in future iterations of you initial MVP concept.

BacklogContinue working through the feature backlog after launch

Software development is a balancing act between time and value. How can you release an app that offers maximum functionality in the shortest time frame? In determining and working toward the software MVP defined during feature prioritization, additional functionality will remain in the backlog. Subsequent releases will involve working through the backlog. That’s why it’s important to make sure you haven’t bitten off more than you can chew with your MVP. You will revisit the backlog anyway. In some instances, you may groom the backlog and reprioritize features as you race to feature complete so previously high priority functionality may be exchanged for something with higher business value.

Remember your teams are human

Sprint planning is integral to the success of a software development project. The meetings allow each team member to realistically estimate how long each task will take. It’s important to remember resources are not machines. Setting realistic timelines together safeguards everyone from overcommitting and under delivering during the development process.

Why release a lean version of an MVP?

Limiting the features in your first full iteration of the product allows you to gather user intelligence with less effort expended. Maybe your customer intelligence and a premonition you have every day at 3pm tells you your mobile or web app idea is a winner. An MVP allows you to put the voodoo aside and concentrate on a working representation of your concept.

Remember: Simple experiences standout

When in doubt — simplify. Creating value for your users isn’t achieved by providing every feature imaginable, it’s achieved by choosing only the features users need. Research your target audience. It’s easy to say yes to features you think users may want. Instead, let your conclusions be driven by data, established use patterns and user empathy. It’s difficult to have a lot of features and a clear user experience at the same time.

Download 3 Mobile Disasters and How to Avoid Them

shutterstock 214745092 copy

Coordinating internal & external development like a pro

Imagine a relay team is running a race and have a target time they must hit to qualify for conference, state or even — say — the Olympics. Regardless of the situation, the payoff is BIG.  Each team member must perform at a certain speed to achieve the goal time. If not, it may be humanly impossible for the other two to run faster and compensate. The team comes in second. All bets to advance to the next stage of competition are off.

The key to achieving a winning result? All members on the team pace together. If even one member can’t keep up, it affects the team.

This analogy is a little like pacing in software development — especially pacing between internal and external development teams all working on different facets of the same project. Pacing work between a team within the parent company and a development team from a software partner can present challenges for many projects. But in this case, the stakes are even higher. Pace to win and beat the competition to market. How can you coordinate closely between internal and external development?

Set aside time for regular meetings

If your project requires splitting development duties between a software provider and an internal IT department, regular meetings between team and project leads are critical. Communication is key to ensure all parties advance at a similar speed and any new functionality can integrate with legacy systems.

Plan on a meeting of the development teams once a week. During the first meeting, identify the completion objectives, who is working on them and when they must be finished. Then, focus the subsequent meetings on sharing status updates and ongoing risks.

Ask these questions in your next cross-functional development meeting:

  • Are we on track?
  • Are there any blockers or impediments to success?
  • What questions or challenges have we identified in the last week?
  • How are we going to set up our test environments and validate success has been achieved before pushing the software to production?

Share information to piece together the complete picture

Gavin Finden, MentorMate Senior Software Engineer – Mobile, has worked with multiple teams all developing for the same project before. One project united three groups. He found sharing information between the teams essential to understand how work the other groups was completing could impact his portion. It’s impossible without open and frequent communication.

Communicating is also key to avoid re-work by one or more of the teams. Hear it from Gavin.

“It’s valuable to coordinate development work so internal and external teams don’t trample on each other, complicating the job for both. It can avoid duplication of effort in some cases, such as when two teams find and try to fix the same bug. It can also make it easier to reuse code the other team is developing. If you know that the other team is about to add some component that you can make use of, it’s more efficient than implementing your own.”

Pro-tip: Plan code review across teams, so every group gets a detailed look at what the other teams are writing.

Coordinating internal and external development teams is one way to avoid a mobile app development disaster. Hungry for more? Read our eBook.

Blog Banner1

Photo courtesy of Passiflora.

Launch Blog 2

3 mobile app development disasters and how to avoid them

Tales of mobile development disasters are nothing new. Going far over budget. Running out of time. Outsourcing development only to find it’s nothing like you originally expected. You’ve heard the stories whispered in conference rooms or shouted loudly over social media channels. One thing’s for sure, you want to avoid it all cost.

Constructing mobile solutions

Just like construction, mobile solutions connect people. In both types of projects, teams are working — hard — to get from point A to B. In construction, that might mean building a new bridge or widening a freeway to physically move people between two locations. While mobile developers don’t need orange pylons or reflective vests, they connect people too — with features, functionality and capabilities that add value to their daily lives.

The key to preventing a mobile nightmare is being able to recognize the warning signs and setting your project up for success from the very start. Who better to share what works and what doesn’t? Our solutions architects, project managers, developers and designers.

So what are three of the most common mobile disasters?

Mobile disaster 1: Far over time, far over budget

No one likes to be late for an important date, especially when that date involves releasing a first to market mobile app. In the case of most app development, every day and every dollar counts. Know how you can make the most of them.

Plan ahead. Even before you start searching for the best mobile app development company on Google think hard about your mobile solution. The simplest question you can ask to prepare for development is, “What problem do I want to solve?” Let that lead you to define your business needs and users. With that in hand, you’re arming your software provider with information to offer you the best guidance in solving the unique need you’ve identified.

Encourage cross-functional conversations. Coordinating closely between any internal and external development efforts are another way to maintain momentum. This means regular meetings and regular communication. Questions like, “What challenges have we identified in the last week?” can keep the brightest minds on your project focused on any blockers or risks that have emerged.

Set up a system of checks and balances. Spoiler alert. Design and development go hand-in-hand. They should never operate in silos. Bringing them together early on ensures your designers are creating wireframes and actions that are feasible to develop within the budget and timeline your client identified. Developers can tell them. By contrast, designers can provide key insight on user experience that could be overlooked without checking it.

Mobile disaster 2: Aimless investing

The results are in. Throwing money at a problem won’t make it better. But, often redirecting development efforts by choosing another software partner can salvage a ship taking on water.

Ask the hard questions right away. When you’re choosing a new software provider, ask references the right questions. Focus on understanding the quality of the end results and level of collaboration throughout. Ask about work created for other clients. Past experience can help you predict future success.

Consider the long-term value. Everyone likes a bargain. But as the hardcore cost-conscious know, when you take a “deal” you may be accepting that a certain level of extra work may be required to bring a recently acquired purchase up to par. Maybe that means patching a hole or adding a zipper.

Now think about value in the tech space. Consider more than pure economy when you’re choosing a mobile app developer. You don’t want to have to worry about excessive paths or fixes as soon as you release. An experienced mobile app development company can help you keep this to a minimum and provide mobile framework that can grow and evolve efficiently as your solution does.

Mobile disaster 3: Asked for one thing, got another

Developing functional, valuable software is as far as you can get from peering into a crystal ball and divining the future. It relies upon clear and continuous communication between clients and software partners along with actionable results to make that anticipated future a reality.

Embrace transparency. Perfection is the enemy of progress. Look to partner with a software provider you wants to show you progress along the way. The only thing worse than a miscommunication is assuming you and your developers are one the same page, when really expectations were confused all along.

Stay involved. It’s easy to consider checking out of the creation process once you’ve onboarded your development partner. You’re busy. Now they’re busy. Problem solved. Well — resist the urge. Decisions will need to be made along the way. Your provider will need to know what you value throughout the process and how well you see the functionality and development addressing your business needs.

Read our latest eBook 3 Mobile App Development Disasters and How to Avoid Them, so you own the development process and it doesn’t own you.

Blog Banner1


shutterstock 229385674 edited

3 uses for architecture design

Architecture design means different things to different people. Partly because its potential to manipulate and engineer technology to serve specific business needs is so varied. Here are three of the top use cases we see within the course of a software development project.

1. Breath new life into a legacy platform.

This scenario is a common one. A business has already invested time, energy and manpower into sustaining and using an existing platform. But, the writing’s on the wall. It just doesn’t function like it used to. Processing time is slower. Users can’t access it on their platforms of choice. Lately, it’s become more of a nuisance than a necessity. Yet — the data stored within the platform is valuable.

Why build an entirely new solution to satisfy the need for more efficiency or wider accessibility? Rather, architect an adaptation so you can maximize the value of your existing solution.

Often, businesses see value in using a historic platform on a mobile device. A simple API will establish this new communications channel.

Reinvigorating an old platform might also involve connecting a new or third-party application with a legacy application allowing you to optimize workflow and advance business processing capabilities.

2. Gain operational control of your platform.

When designing a consumer-facing solution, it’s easy to focus on the experience — how users will interact with your solution and what they will gain. That’s the right approach. After all, solutions with staying power are those that offer the most value.

But, a partner invested in your success will encourage you to take a step back and circle around for a 360 view of how business users will engage with and manage the solution. For instance, say a user has violated the terms of engagement with your solution — maybe it’s a blog or community. How do you revoke access? Or, say a user wants to unsubscribe. How can you ensure they will no longer be contacted? It doesn’t help anyone for the owners of a solution to be helpless in maintaining it.

The answer to all this and more is a simple two-word phrase with near limitless potential: Admin panels.

Admin panels give you the operational control you need to participate in, manage and own your software. Building in this feature can be easy to overlook, but the visibility and control they provide are critical to maintain a successful user experience.

3. Leverage the value of third party services.

Third party services are a key way businesses can redirect their time and focus custom development on the specialized features unique to their value propositions. Does it make sense to expend effort custom coding features like digital payment processing or address validation? Third party services do this and do it well. By paying to access and incorporate, the services add value for comparatively little cost without the onerousness that comes from building or managing them.

Third-party services also excel at managing batch data rather than one-off calculations, so they’re a perfect addition to any architecture design toolkit for retailers or manufacturers.

Even more uses for architecture design

+ Relational and NoSQL Databases
+ Queues
+ IaaS Platforms
+ Multi-tenant SaaS platforms
+ Content distribution networks
+ Application servers
+ File and object storage
+ Load balancers
+ Legacy systems integration

Want to learn more about the potential to incorporate an architecture design initiative into your next project? Talk with us.

Blog Banner1

Web grid 04.28.15 1210x423

Guide to MentorMate: Succeeding as an employee or client

I joined MentorMate in 2001. MentorMate was a very different company then. Founded by Björn Stansvik, it began as an idea. How would mobile technology revolutionize education? Björn came to my classroom at Eagan High School. I was sitting in U.S. History class and listened to his presentation about a Palm Pilot teaching application he built. As many of the people who have met Björn have experienced, I was entranced by his vision.

I went up to him after class and asked how I could get involved. That started my journey with MentorMate. I’ve seen the company grow from one employee/intern/contractor (myself) to now over 275 team members with a world-class reputation for solving problems with technology.

I’ve worked extensively with both our own team members and with our clients over the past 14 years, I want to share some of the opportunities and experiences you should expect from MentorMate.


Always remember, you control your career here. If you know what you want and where you are trying to go, share it. The ability to design your own career is one of the most inspiring parts about working here. This intangible benefit has empowered me throughout my 14 years at the company.

Every team member has hopes and dreams, but don’t assume they are known and understood. This is occasionally true, but you can make sure it’s true by talking about it. You are your own best advocate.

Your goals mean something, not just to you, but to the team you work with.

Once they are understood, the organization automatically responds by re-aligning itself to help you achieve those goals. That’s a unique and quintessentially MentorMate characteristic.

I started at MentorMate by organizing focus groups, then running those focus groups. Next I wrote technical specifications, then  project management, then delivery. Finally, I came to lead our Strategy and Innovation effort. Two things made this evolution possible. First, I worked hard and always tried to keep the organization’s needs and interests at heart. Second, I knew what I wanted and shared it openly and freely with others.


Being a client of MentorMate is a completely different experience compared to working with other companies. We are recognized for our willingness and desire to understand the WHY behind your projects and initiatives.

We’re committed to working with you as a strategic advisors and want to help take ownership and rectify your unique challenges. That’s the MentorMate way.

Some of our largest value can come when clients don’t rely on us exclusively as a technology partner. Technology is no longer built in a vacuum, and having an advisor who cares about your business as much as they care about solving the problem in the right way technically is a very powerful combination.

We empower our clients with all the information at our disposal and details about possible future outcomes. We are completely transparent, so you are empowered to run your business efficiently and strategically.

Want to learn more about partnering with MentorMate? Talk with us.

Blog Banner1

shutterstock 227730694 750 750x423

What’s eating at your hard disk?

You’ve looked once. You’ve looked twice. Yet, you don’t see anything in your directory scan that could account for how little hard disk space you have left.

Use this command snippet to dig deeper and see a list of all files and folders (including hidden ones) and the amount of space occupied by each.

Perform the following steps:

On the terminal window, type the following command on the

du -shc .??* *

This outputs the following result:

4.0K .CFUserTextEncoding

20K .DS_Store

4.0G .Genymobile

0B .Trash

1.0G .android

4.0K .anyconnect

12K .bash_history

264M .cocoapods

164K .config

4.0K .cups

7.9M .gem

4.0K .gitconfig

4.0K .gitignore_global

4.0K .hgignore_global

448M .local

188K .npm

4.0K .profile

4.0K .ssh

24K .subversion

4.0K .viminfo

8.2M Applications

21M Applications (Parallels)

10M Desktop

48G Documents


45G Library

8.0K Movies

84K Music

8.1M Pictures

0B Public

114M doxygen

4.0K ngprs.keystore

16K patch.diff

1.4G pumpkinprivate

7.2M securehalo-ipad

1.1G sw-ios

120M sw-ios-smartview

102G total

That’s it. Problem solved. Consider yourself smarter and more storage savvy. Share your tech tips in the comments section.

Note: This solution works for OSX (and other UNIX based operating systems.)

Looking for more advice to optimize your existing platforms? Talk with us.

Blog Banner1

The 10 Best Apps for Oncologists 735x423

The 10 Best Apps for Oncologists

Cancer is a word that strikes fear in the hearts of most of us. There is no way to know what it’s like unless you or a loved one has experienced it. For many people, struggling to survive cancer is the toughest battle they will ever have to fight.

A recent research study examined the use of ‘war’ related metaphors like ‘fight’, ‘survivors’, ‘battle’, etc., to refer to cancer, and concluded that patients are more likely to show less self-restraint and have less limitations if they feel they are about to enter a battlefield. And often, they will choose more aggressive treatment procedures to tackle their ailment head on.

What does this have to do with apps for oncologists? We believe this study shows doctors that patients need to be prepared for a fight. It shows that the most up-to-date and aggressive treatment is often the difference between life or death, and that, if sent into battle armed also with doctors who have the best information available to them, cancer patients will maintain a positive, hopeful attitude.

Why do Oncologists need apps?

Apps aren’t just for gamers and hipsters. The technology field has also been busy doing its part to make diagnosing and treating cancer easier for oncologists, patients and researchers. These latest applications can keep tech savvy doctors on top of the latest symptoms, diagnosis, and treatment procedures, and bring peace of mind to patients.

Top 10 apps for Oncologists

We went straight to the source,, home of the journal Oncology, to bring you this list. Here they are, in no particular order.

MedPage Today and CollabRx have developed Cancer Rx, “…the first mobile app to aggregate and contextualize the world’s knowledge of genomics-based medicine in oncology.” It is a warehouse of updated information which offers guidance for treatment based on its database of tests and results.

Along similar lines, but not quite as comprehensive, is PubMed on Tap which offers medical resources by accessing the PubMed Central database.

inPractice mobile app lets oncologists access PubMed resources. Clinical trial registry and guidelines to treatment procedures can also be accessed with this app.

Treatment guidelines can be referred to in detail with the help of the National Comprehensive Cancer Network app, available on smartphones and tablets including iPhone and Android. This mobile app ensures effective treatment by helping physicians implement guidelines smoothly.

Information related to medical news, as well as guidelines to be followed during treatment of cancer can also be found on the Medscape app. It has an estimated user base of more than four million in the United States alone.

BrownZine offers a collection of e-journals with articles and references. These can also be downloaded as PDFs. With the help of this app doctors can scan through numerous scholarly papers from a particular educational institution or any other source.

For information on medications, Micromedex Free Drug Reference app is one of the trusted resources for prescription drug reference. Details on medicines such as name, class, side effects, etc., can be found here.

QxMD’s Calculate, where healthcare providers and researchers can search for and find calculations and formulas, is supported on iPhone, iPad, Android, and BlackBerry.

To help doctors find out more about secondary ailments cancer patients may be affected with, along with support on how they should be managed, diagnosed, and treated, there are the Johns Hopkins Guides.

Keeping patients up to date in their treatment and surgical procedures is the main objective of the Draw MD app. It allows doctors to visually communicate anatomy, conditions, procedures and concepts with patients to improve understanding, retention and quality of care.

And Last But Not Least…

The app chose as one to watch is OhMD. It provides a platform for oncologists and their patients to communicate through simple and secure texts. It meets the stage 2 messaging criteria and will work on the patient portal in use.

Apps are being developed regularly, many with specialized focus areas to assist physicians in adopting the best treatment procedure for their patients. We are certain that they will continue to be improved upon and we will see new apps being developed as doctors continue to help their patients with their battle against cancer.

If you would like to learn more about this and other digital health topics register for MobCon today.

Photo Credit: agencia_Investigación y Desarrollo via Compfight cc

A Quick Look at Cross Platform Philosophy 729x423 729x423

A Quick Look at Cross Platform Philosophy

When evaluating or designing an approach for reaching users across a wide variety of platforms and devices, MentorMate applies our core mantra of ‘Business Needs First, From a User’s Perspective’. This means that the chosen solution should support the outcomes and end state desired by the business in a way that supports and engages users effectively.

Across the industry, there is a significant amount of literature and time dedicated to the notion of Cross Platform Frameworks. These frameworks attempt to reduce development time and complexity by abstracting shared components across two or more mobile mobile platforms and optionally the web platform. For the purposes of this document, only iOS and Android are considered.


Cordova is a framework that acts as a layer between HTML5-based applications and native capabilities. With Cordova, the native capabilities of mobile platforms such as Contacts Integration, GPS, Filesystem, and other sensors are exposed to the application via a series of Javascript APIs.

Cordova applications are built by taking a client-side web (no server side code is supported directly within Cordova) application of one or more pages and enriching it with native capabilities. Cordova applications can be mixed with native functionality and screens, but this use case is less often desirable.


If the application you are developing is an offline client-side responsive web application, you have already written most of the code that will allow your “application” to function. This means that a well written web application utilizing a framework such as AngularJS can be leveraged as-is to begin offering offline mobile application experiences.

One of the best aspects of Cordova is that it allows developers experienced in the Web platform to begin building mobile experiences that take advantage of mobile paradigms and capabilities without significant retraining.


Cordova has two main downsides. . First, all of your UI will be web-like. This means that your input fields will look like web forms rather than native input boxes, it means that transitions and animations will render and perform like those found on a website (or worse), and that standardized components such as the Android Action Bar, or the iOS Tab Navigation cannot be leveraged by your application. By not matching the standards of iOS and Android, your users will need a small amount of additional time adapting to your custom experience, or may feel like the experience is less modern. This can be mitigated somewhat through creative experience design and/or the use of cross platform design frameworks such as Material Design, but will still make your application feel less like a smooth shiny native application.

The second core downside is that Cordova applications are limited by the Cordova framework. The Cordova framework is always going to be several releases or features behind “main line” Android and iOS. A great example of this is that there is still not an official way to build Android Wear or Apple Watchkit applications with Cordova. There are 3rd party libraries (including one we have written), but they don’t have the focus or attention that the native tools have.

There are other downsides with Cordova for Android such as the widely varying versions of the WebView that ship across multiple Android devices. In All Android versions before 4.4, the WebView was bundled with the OS and immediately out of date upon shipping, meaning new features of HTML5 are inaccessible. This can be worked around by shipping Android applications with a custom-built WebView called crosswalk using the latest version of Chromium, but this introduces another dependency and more complexity.


Xamarin is a framework indirectly supported by Microsoft that allows developers to build iOS, Android, and OS X applications using C#. These C# applications can be designed to have both a data and services layer built in C# as well as a User Interface built in C#, or developers can blend C# and native functionality.


Unlike Cordova applications, Xamarin applications are compiled instead of being interpreted at runtime. This means Xamarin applications have better performance than Cordova applications. Additionally, Xamarin applications use reflection to expose native APIs automatically, meaning that Xamarin developers do not need to wait for the Framework to update in order to gain access to new or device-specific native APIs.


Xamarin is a new platform It does not have the same level of extensive and numerous application frameworks as HTML5. Tools like Xamarin Forms which allow users to build shared UI code that renders well across platforms are still in their infancy, and can create significant barriers to building top-notch experiences. User Experience elements such as gestures and animations can be difficult to achieve due to the fundamentally different ways these are natively achieved by the platforms.

It should also be acknowledged that because Xamarin ties so closely to the platforms, many things that one might expect to be cross-platform may not be. One example of this is Wearable interfaces. If you are building wearable experiences using Xamarin, you must still build them twice to target both iOS and Android.

According to Xamarin, best of breed applications are able to achieve around 70% of the code between platforms, so expect to be working on platform-specific behaviors as well as overcoming unexpected issues with the shared code.

Last, to get started or to continue working in Xamarin, each developer will need a license to Xamarin, which serves as an additional barrier to entry for new team members to get up to speed.

Native Development

Native development of an application for each target platform may seem to be the most costly approach, but with fewer risks and compromises required the cost can sometimes be less than an equivalent Cross Platform application.


Across both of these Cross-Platform frameworks, there may be an overall reduction in development time in exchange for limiting the types of interactions and experiences that can be built to those that are “lowest common denominator”, but these platforms are evolving every day. This must also be considered in combination with the additional developer skill sets implied and required by the use of an additional framework. For a Cordova solution to work successfully, the development team must be familiar with both Blink and Webkit capabilities and peculiarities (including their mobile components), as well as the best practices for building mobile applications. Xamarin developers need to understand the iOS and Android platforms and capabilities as well as have extensive experience building C# applications.

Finally, packaging and designing an application should be done intentionally for each platform. Each store has separate submission and review processes. Things like screen shots and marketing text may be significantly similar, but users hate seeing platform-specific images for the wrong platform in either store, and may risk the rejection of your application.

Writing User Stories for Mobile Apps Adding Context 729x4231 729x423

Writing User Stories for Mobile Apps – Adding Context

I saw an interesting presentation at MobCon 2014 from Josh Bernoff over at Forrester Research on the concept of the Mobile Moment. This is the idea that there are two additional dimensions that you need to account for in your mobile apps: time and space. That is, when are your users using the app and where are they using it?

The Mobile Moment concept struck me as quite powerful: knowing where and when users are interacting with your app can help you craft more powerful, intuitive features. Mr. Bernoff provides examples for Starbucks in which the mobile experience might change if you’re not at Starbucks, standing outside a Starbucks, standing in line, at the register, and even after the purchase. Josh is now even talking about Micro Moments, in which the user is interacting with your app (or maybe, with only a push notification from your app) for a few seconds only. This got me thinking about the mobile apps I’ve been working on, and it made me think that I might be leaving out some important details in my users stories.

dilbert userstories

In the agile development world, user stories are king. They describe who will be using a feature, what they will be doing, and why they are doing it. Typically, they go like this:

As a [user role] I want to [perform some function] so that [some value is realized]

And this works really well as a starting point of discussion when reviewing product backlog items. The development team knows three dimensions of the requirement:

  1. Who will be using the feature
  2. What the feature is
  3. A notional idea of why the feature is important

Knowing these dimensions of the requirement helps guide the team to make the right decisions when there is ambiguity and helps guide the discussion of the story’s acceptance criteria (the how). Other forms of requirement development (you know, those requirements that start with “The SYSTEM shall…”) can often leave these dimensions out.

So the question then is: How do we account for the two additional dimensions represented by the Mobile Moment? The tried-and-true template doesn’t have any placeholders for where or when. Just who, what, and why. The easiest way is just to modify the template, adding the where and the when:

As a [user role], [in a certain mobile moment], I want to [perform some function] so that [some value is realized]

Let’s imagine that you are working on requirements for an urban touring app, and you want your users to be able to see information about different locations on a tour. You might write a story like this:

As a tourist I want to pull up Wikipedia articles about each stop on my urban tour so that I can learn more about each location.

urban street tour

The product development team would discuss that story and they may end up developing a feature in the app in which the user can pull up a map of the tour, choose their current location on the tour, and then tap a button to learn more about that location. While this works, it isn’t ideal. The tourist has to go through several steps to get to the information she wants.

How could capturing the mobile moment in the story help? Let’s re-write the story to include the mobile moment:

As a tourist on an urban tour at a stop on the tour I want to pull up a Wikipedia article about the current stop so that I can learn more about it.

The product development team would discuss this story and decide that the mobile device can detect that the tourist is on a tour, and where on the tour the tourist is, so they may develop a feature that launches the Wikipedia entry for the current location when they launch the app. They have captured that tourist’s mobile moment, providing her exactly what she wanted, when she wanted it.

The problem with including the Mobile Moment in the user story itself is twofold. First, writing user stories that coherently capture who, what, and why is hard enough. It often takes a while to format the sentence in a way that both makes sense and captures the intent. Adding the where and when factors complicates things even more and might frustrate the product owner trying to capture the requirement in the user story format. Secondly, not every story has a mobile moment. In fact, some apps, such as games, will have very few Mobile Moments.

Another approach to capturing the mobile moment is to place it in the body of the user story, near where the acceptance criteria reside:

As a tourist I want to pull up Wikipedia articles about each stop on my urban tour so that I can learn more about each location.

Mobile Moment: While on an urban tour, at a tour site
Acceptance Criteria:

  1. Item 1
  2. Item 2


This method keeps the Mobile Moment in the developers’ minds as they are reviewing the story and helps drive the discussion, but doesn’t get in the way of the user story itself. It may not be as effective as including the moment in the story template, but it also doesn’t get in the way if the story doesn’t have an obvious Mobile Moment.

A third approach is to place the Mobile Moment in the acceptance criteria themselves. I don’t like this option because it intermixes the important where and when with other run-of-the-mill acceptance criteria (i.e. the how). This diminishes their importance and top-of-mind relevance.

Some apps, such as Uber and Lyft, are defined almost entirely by their mobile moments, some have few or none at all (Angry Birds?), and most fit somewhere in-between. If you don’t have a way to capture these moments in your user stories, your development team won’t know about them and you’ll end up missing out on important opportunities. Find a way that works best for you to represent the where and the when in your user stories, and watch your development team turn those mobile moments into killer features.

Be The Change You Wish To See In Your Workplace

Be The Change You Wish To See In … Your Workplace!

I started my career in HR with a let’s-give-it-a-try attitude, and have yet to regret my choice. Developing connections and learning what is special about everyone is fun and exciting. Each person I work with is unique and each challenge must be approached differently. It is this individuality that sometimes gets lost when joining a larger organization where a “one size fits all” mentality is sometimes applied. Often, those leaving a large corporation comment that they felt faceless, like a small fish in a large pond. They prefer to work for start-ups or at least mid-sized companies where they still have a chance to meet all of their colleagues and express their opinion.

What if your company experiences rapid growth? The family atmosphere starts to vanish because keeping up with all of the new hires becomes difficult. Both team members and managers want to work with enthusiastic people, passionate about their job; but how can this be achieved if you never get to know your coworkers in a larger organization?

big company

The most effective strategy I have seen for keeping up workplace engagement when a company is rapidly growing is making sure colleagues have enough space and time to meet and exchange ideas. I call it EIIC – Employee Initiatives and Inside Communities. During my career, I have seen charity engagements, knowledge sharing initiatives, dancing lessons, employee boards for improvements and inspirational gatherings all coming from the employees. And it does not need to be solely work-related – hobbies and interests, the stories we tell during a gathering with friends – it all counts!

Sound good? Get started. Build your EIIC initiative in three easy steps:

  • 1. Listen!

    We usually hear rather than listen to the ideas of others, especially if they are not focused on the problem we need to solve today. Choose to be a good listener by devoting part of your weekly schedule to others on your team or organization and what they have to say. A self-organized salsa workshop in the office is not a waste of time, just like any other initiative your people are passionate about.

  • 2. Support!

    The financial cost of investments such as bike parking, transport for a volunteer initiatives, space for dance lessons or a pizza party tends to be less than the hours spent in meetings pondering over employee engagement.

  • 3. Reward!

    Enough has been written on the topic of employee reward and recognition, so I will let you decide on how to approach this matter. Just one tip: be creative.

Gandhi once said, “You must be the change you wish to see in the world.”

Your company is like a small world. You must be the change you wish to see.