Necessary but not sufficient

With great effort, you have got access to the key stakeholders of the product organisation. You also identified the specific persons, their roles and responsibilities in the organisation. What are you going to ask them? You would obviously focus on the software product’s features and functionality, because well, that is what you need to know before designing and developing any software application. How about a few questions on the Technology? Well, yes of course, because after all, you are developing the software product using a specific Technology. Let us discuss if these are good enough to get you a head start in the product development or do you need to focus on any other areas during your stakeholder interactions.

Technology or ‘Trick’nology

While nobody can deny the significant role played by Technology in our lives today, one needs to be wary in focusing only on Technology and ignoring the rest. Technology is verily what IT and Software development organisations like us thrive on and I am in no way suggesting to drift away from it. However, I support the view that Technology should be seen as an ‘enabler’ and a means but not the end. All products that have been invented or innovated so far, did not succeed merely based on the technologies used to build them. The underlying technologies in each of these products, if I may call so, helped achieve some business objectives to their users-from the Potter’s Wheel to Radio, from Mainframes to Laptops, from ERPs to Web Applications and from Java to the Multi-Touch Interface. The moment one focuses only on technology ignoring other aspects, that product is bound to fail.

Like ‘Marketing Myopia’, product companies might get into what I call ‘Technology Trap’ leading to the failure of their products. This happened with Borland when they focused on Delphi as only a technology platform and could not pursue advancements and evolve their platform like other competitors. Same was the case with Konica and Kodak were focusing on making better film roll technology, while others such as Canon, Nikon, Olympus moved on to the Digital image technology.

It takes a lot of courage for product companies to come out of this trap. We had seen a real life instance of this ‘technology trap’ in one of the projects to reengineer a university administration suite. This suite was originally developed in LISP, about 15 years back and the product owners thought it was high time they made it modern. So, we were entrusted with the responsibility of reengineering it to Microsoft.Net platform. In one of the screens of the proposed modern platform, we noticed that the development team gave a solution which used Acrobat PDF to preview the schedules and reports. Obviously, we were puzzled why this was done, because PDF is not a suitable solution to be used for WYSIWYG (What You See Is What You Get) interface. When we probed the team, we understood that they did not think of alternatives and tried to imitate the solution applicable to the previous technology. Similarly in another project involving an automated information system, when user logs in he/she had to land in a blank page with very few options. The older technology solution did not use database and used flat files instead. Due to this, they could not maintain the user details.  However, even in the newer version of the product on modern technology platform, after user logs in, personalised welcome message and user-specific tasks could not be provided by the team. But, what stopped us from including personalisation in the modern technology solution?

Prevent ‘Featuritis’

On the other hand, a few people specifically those in the product management and business analysis areas tend to focus more on the features and functionality to the software product. They focus all their energies in adding new functionality and improving existing features. If this is backed by sound logic, business vision and user research, they are surely on the right track. However, this is done more as a pressure from the competitors and to keep up in the race. Focus on features is futile, because if you have created a product with 100 features, your next competitors will create another product with 200 features the very next day. Google, known for its innovation and user-focused products had been successful all along since Google Search, Gmail, and Android O.S. But even Google could not create the right ‘Buzz’ because I think they followed the lead of Facebook, and even Yahoo on this specific offering and could not pursue their core user-focused innovation. Just a day before Google announced the launch of Google Buzz, Yahoo had already implemented similar functionality, and Facebook did it two years back.

First, get on the BUS

So, you might ask what is to be done during the stakeholder interviews. While understanding the Technology and Functionality perspectives is necessary, it is not sufficient. We also need to understand the other perspectives, what I refer to as BUS, i.e., Business, User and System. I give below an indicative list of areas that could be part of each of these perspectives.

• Business – Organisation’s vision, Business Strategy, Target markets, competitors
• User – Customers, consumers, primary user groups, usage behaviours, and context of usage
• System – Product roadmap, scope of features, Technology constraints

Why do we need to do BUS Analysis

As they say, for the success of any product, we need three aspects:

• Business viability
• Technical feasibility
• Continual reliability

To this list, I add two other dimensions – ‘sound usability’ and ‘optimal quality’. To get sufficient responses to the above perspective, one needs to ask relevant questions to the respective stakeholders. This would help get a handle on the objectives, expectations and grounded logic, based on which we can provide solutions  that are practical, feasible and well within the budget, time and other resources of the product owners.

What are the challenges involved in interviewing stakeholders?

Stakeholder interviewing is a scientific technique that involves expertise, experience, maturity and a bit of domain knowledge in the area of the product. It includes asking the correct questions to the correct persons (based on their role and background) to get the correct responses. Even more important than the interviews is the analysis of the data collected from the interviews. It typically takes about twice the time for analysing the interview data and creating a report. The key challenge is to define this very clearly in the plan and let the project stakeholders know about this activity, deliverables and the value created thereby.

After the stakeholder interviews and analysis, we are now poised to define the user profiles and related usage information. Let us discuss this in the next post with some examples from my real life product engineering cases. Until then, ciao!