Independent software development companies and contractors have more responsibility than employees typically do in managing customer expectations and in helping them prioritize development. There are always trade-offs when prioritizing development tasks, but the gap in understanding between the clients and the contractors can lead to problems if not managed proactively. This is an issue in all software fields, but it is particularly relevant to mobile development due to the explosive growth in mobile apps and the variety of customers wanting Android, iOS, and other apps developed.


The first thing to consider is how your customer views their feature requests. Customers’ requests or demands might be out of the bounds of what’s possible. While rejecting unreasonable feature requests is an option, I recommend unraveling what really interests the customer and then proposing a reasonable and perhaps new way to accomplish what they want. A flexible customer will delight in the fact that their expectations are met, even if it’s not in the original way they envisioned.


Many nontechnical customers don’t view software development as a creative process, so they don’t understand why they can’t be given a schedule that will be followed exactly. It’s important to educate the customer on the risks and unknowns at the beginning of a project; if you skip this step, the customer might be upset the app didn’t turn out exactly as planned.

Some customers might move on to another development team that is willing to make a promise of fixed results, fixed price, and fixed time. Those customers would be difficult to work with anyway.


A reasonable assumption is that a customer will (at least initially) prioritize features by what they want most. If the customer isn’t involved in implementation, the difficulty to accomplish each task may seem irrelevant. From your point of view, more complicated tasks will take more time, meaning that performing longer tasks first can squeeze out everything else.

If the customer is willing to participate in the prioritization process, they are much more likely to get the most from their development dollars. This means changing priorities as the project moves on and more is discovered. As that occurs, a useful lens in determining priorities is the Minimum Viable Product. This concept has become more popular in the last few years for a good reason–startups and small businesses don’t always have loads of cash to burn before they get a product to market.

Ideally, customers are stakeholders in costs and schedules, which lets the team collaborate and prioritize based on the total result and allows as many high-priority items to fit into the schedule as possible. Conversely, fixed-price contracts can lead to a “throw-it-over-the-wall” approach that puts more pressure on you and results in unrealistic expectations. Care should be taken with such contracts.

Get the app to market

Sometimes it’s not a matter of getting the perfect product to market, it’s a matter of getting any product to market. So, when faced with difficult-to-implement features, you must ask your customer: Is this feature vital to the minimum product that can be released, or can it be safely postponed until the next version? Only when the customer is a stakeholder in schedule and cost will they make prioritization choices that support the team in building the best quality product possible.

Note: This TechRepublic post originally published on August 13, 2012.