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. Executives are paid to be concerned with costs and revenue potential.
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 executives, project managers, and 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 the job of a business analyst 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 business analysts. 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 business analysts 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. BAs should think, draw, and write – in that order – at all times.
Understanding the skills and tools of the UX/UI Designer helps a business analyst 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 business analyst. Obtaining basic UX/UI knowledge is a simple and fun way to improve your skills and advance your career as a business analyst. Your customers and delivery teams will thank you for it as well!
About the Author
Dave Shaffer is currently the Manager of Business Analsyis at Reed Tech Managing a team of business analysts within a Business Analysis Center of Excellence. He has practiced Business Analysis within the pharmaceutical and manufacturing industries since 2002 and may be reached via his LinkedIn profile
Powered by Facebook Comments