There is a lot of insight a developer can offer when it comes to reducing costs associated with building web applications. While few developers have MBA degrees, we are “in the trenches” when it comes to bringing a project from ideation to completion. We see where projects go astray and where in the process complexity gets introduced, timelines get pushed out, and costs rise.
Failed features are a significant cost to any project. I’m defining a failed feature as a feature which gets implemented by the developer correctly, but which was ill-conceived in the planning stages. There’s no 404 error pages, just poor user experiences that don’t serve the application’s aim.
To mitigate failed features, there is a first principle that I think clients should apply at the outset of any software project:
Align the application’s features with business goals.
“Have attainable goals,” is something you hear in a range of industries – from fitness to financial planning. For example, it is common when designing an investment portfolio to come up with a baseline for what you’d like to have saved by the time you retire. Goals help quantify short-term success (meeting monthly savings goals) and bring context to immediate financial decisions (going on an extravagant vacation vs contributing to the 401k).
In many regards, defining business goals is far harder than designing a feature for an application. Developers can implement an idea, but if the idea is not well grounded or refined enough, the implementation does not matter. Application consumers will not be able to use the feature in a way that translates to success for the business. For all intents and purposes, the feature is “broken” and costs are about to go up because it will need to be fixed.
This is why coming to a consultancy with a list of features is problematic. Features are not grounded in any sort of reasoning; business objectives are. Enter the planning process with a set of business objectives for the application.
Let’s take a simple case. A client is overhauling their marketing site. They sit down in their first planning meeting with the designers and developers and say “we want a blog.” A blog is a feature – it is not a business objective. What would be more helpful from the designer and developers’ perspectives is to hear: “we want a way to show prospective clients that our firm is transparent.” This a business objective. It informs the designer that there is a target audience to design for (prospective clients). It tells the designer a little bit about the client’s values (transparency). Yes, it may lead to a blog, but what’s important is that it grounds the feature with a purpose.
Features must align with business goals, because they create the theoretical framework in which the application operates; the alternative is an aimless application with a lot of code, a lot of options, and a lot of usability problems. Designing a user experience which gets the consumer from point A to point B becomes difficult because there is not a logical consistency to the elements in the application. Features do not have a unique roles, and so the designer cannot delegate responsibility in a predictable manner.
Features that are not aligned with business objectives are expensive.
It goes without saying, but clear design thinking translates into cleaner implementations for the developers building the application. Features can be added, removed, and enhanced without hurting other elements of the application. Code becomes less coupled, is more maintainable, and can be better tested.
Features without well-defined roles don’t have a place in the application’s ecosystem, and so they often fail. This is a worst case scenario. It means that users can’t interact with the application in a way that’s meaningful for the business. And since these failed features need to be fixed and re-worked to meet the business objective (which should have been known and communicated at the outset of the project “discovery” process), the client has expended the following resources:
- the time that went into designing and implementing the failed feature
- the cost that went into designing and implementing the failed feature
- the time that will go into designing and implementing the correct feature
- the cost that will go into designing and implementing the correct feature
This is to say nothing of the opportunity costs. While one client is figuring all of this out, a competitor who aligned their features with their business objectives and “got it right” on the first attempt is gaining happy, new users.
When a businesses hires a software consultancy to develop an application, they’re bringing in skills and expertise from the outside. It’s unlikely that a developer is going to advise a client on how to gain market share, and it’s just as unlikely that a client is going to open a designer/developer’s eyes to a new application feature. Rather than planning an application around a set of features, clients can make the most of a consultancy’s resources by coming to the planning stages of a project with well-defined business objectives.
