Henry Ford once said “It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages.” Unfortunately the software development industry does not always remember this fact.
High profile failures such as Windows 8 and the Blackberry 10 are constant reminders that you must listen to your customers and deliver a product that solves a problem.
Windows 8 was a product that solved a problem that Microsoft invented. No one wanted a touchscreen laptop that had the same interface as a Windows phone. Does anyone actually have a Windows phone? I remember my first experience with Windows 8. I had to use an old laptop to look up how to shut down my brand new Windows 8 machine. It was a terribly frustrating experience.
The Blackberry 10 failed for similar reasons. Customers had difficulty turning the phone on and once they did they couldn’t figure out how to access their email or the internet. Windows and Blackberry simply refused to listen to their customers. They also created products that did not solve a problem.
To learn from these failures we must understand there are three main factors to consider for every software product:
- Viability – how much will it cost to build and how much revenue can it provide?
- Feasibility – is the product technically feasible to build?
- Desirability – will our customers want the product and does it solve a problem for them?
In my experience, software development groups have a tendency to focus heavily on Viability and Feasibility while neglecting Desirability. This is a recipe for guaranteed failure of your product. If your product isn’t desirable then it is a disaster regardless of how well you managed to budget and timelines.
Software development teams are comprised of many different roles. Executive management will always be laser focused on the Viability of the product. Costs and revenue potential are what executives are paid to be concerned with. Project management and Technical roles are always heavily interested in the Feasibility of the product. If we don’t have the resources or technical skills to build the solution then we can’t move forward. The desirability of a product can easily fall off the radar of the Exec’s, PM’s & technical leaders. Ironically it was Bill Gates who said “Your most unhappy customers are your greatest source of learning.” Microsoft listened to their unhappy Windows 8 customers by scrapping the design and giving Windows 10 away for free. The tremendous reputational and financial loss drove Microsoft to have a stronger focus on desirability for their Windows 10 product.
So who should be focusing on desirability?
I think the Business Analyst is in a great position to constantly focus on the desirability of the product.
A well-defined requirement elicitation process must be focused on defining the problem the business is trying to solve for our customers. If defining the problem is the first step in your requirement process you are on the way to guaranteeing that the delivered product will provide value to your customers. Throughout the development process you will be able to monitor if the product is actually solving the problem. Additionally, your requirements should be directly related to solving the problem. It is a BA’s job to question the value of every proposed requirement that product owners want to add. If the requested feature or function is not directly related to solving the problem then it should be taken out of scope.
Focusing on the customer experience and the desirability of the product throughout the entire requirement elicitation process is our responsibility as BA’s. It’s very easy to concentrate on costs, revenue, and timeline issues while neglecting the customer experience. Never forget that our customers are much savvier computer users than they were in the past. They are familiar with using Amazon, Facebook, Netflix, Google and many other major products without requiring training or a user manual. They will expect the same from the products your team develops. If your project plan has a task for writing a user manual it is officially time to panic!
Some organizations are lucky enough to have a mature Product Management group or dedicated UX/UI Designers. These organizations are typically committed to having a focus on the desirability of their products. If you are lucky enough to be in an organization with strong product management and UX/UI design then you should be tightly integrated with those folks. In fact, adding UX/UI skills is one of the best ways to improve your overall BA skills. The best BA’s utilize visualization and storytelling in their requirement process by providing low fidelity wireframes, sketches, or whiteboard drawings to stimulate conversation and uncover the true business needs. BA’s should think, draw and write in that order at all times.
Understanding the skills and tools of the UX/UI Designer helps a BA focus on the desirability of the product and ensure the customer has a positive experience using the solution. There are numerous online courses in UX/UI that are reasonably priced and provide a solid background in the profession. In my opinion Steve Krug’s book “Don’t Make Me Think” should be mandatory reading for all BA’s. Obtaining basic UX/UI knowledge is a simple and fun way to improve your BA skills and advance your career as a BA. Your customers and delivery teams will thank you for it as well!
Author: David Shaffer, Business Analysis Manager, Reed Tech
Dave is the Manager of Business Analysis at Reed Tech in Horsham, Pa. where he is focused on mentoring Business Analysts and constantly improving the maturity level of Business Analysis within the software development group. He has established Business Analysis Centers of Excellence within the pharmaceutical, government and manufacturing industries since 2002 and may be reached via his LinkedIn profile https://www.linkedin.com/pub/dave-shaffer/0/894/681
Email: [email protected]