Agile Development, Behavior Modeling & Design, Business Analysis, Information Technology, Innovation, Product Development, Requirements Development, User Analysis, User Experience, User-centered Design

It is beyond doubt that the current times of digital, mobile and social age demand professionals who are versatile, agile, sociable and dynamic. Business Analysts and product specialists are no exception to this. Whether its due to the industry demands, peer pressure, market needs or pure evolutionary tactics, BAs today are far more leading-edge, competitive, assertive and visionary contributors to the products, processes and businesses, at large. From an also-ran team player role, new-age analysts have come a long way as the multi-disciplinary, multi-skilled and multi-dimensional professionals. In this post, I will touch upon the many facets of the new-age Business Analyst and how they are adapting to the continual changes happening in the spheres of business, technology, professional and personal lives.

Emergence of the new-age BA/PO

As we discussed in the previous posts, there have been several factors that led to the emergence and evolution of the Business Analyst. The BA today moved on from just a requirements owner and a document expert and is now addressing several facets around products, processes, business and technology. Their focus still remains pretty much around the problem space, compared to the facilitation role in the solution space. The analysts identify problems, dependencies, needs and opportunities. However,  products, processes and business domains. The BAs today have been involved in scoping, release management, continuous engagement with customers and users, strategising, laying out roadmap, and working with multiple teams.  In a nutshell, the Business Analyst of the modern age is much like a leader, architect, soldier, team player…all rolled into one.

NBA_Leader.Architect.Soldier.Team Player_Texavi

Leader, architect, soldier, team player & more – the new-age BA

From being an analyst, the BA needs to transform into a leader, architect, soldier, team player and perhaps many more such roles, all rolled into one. Of course, they need not be all of these roles at the same time. The analyst today has to don one, few or all of these various roles based on the context, time, stage of implementation as befits the occasion. During the initial stages, the emphasis could be on being an architect, while during the scoping it could be that of a soldier. However, throughout the project, or initiative analysts have to keep their hat of leader and team player, no matter what stage the work is in. I touch upon the four primary facets of the new-age Business Analyst in the following paragraphs.

1. Sensible leader, not just an also-ran

You can’t talk enough about the all-imperative skill and art of analysts to work with people. They must have their hands firmly on the pulse of the different categories of people. These include the various stakeholders – direct and indirectly responsible for the product and process, from senior management all the way through to people working on the factory floor. As an able leader, the analysts must not only lead the way, but also set an example by following and working along with the team members. They should  listen actively, take steps pro-actively and be able to put in their efforts with sustainable passion, drive and commitment to achieve this shared vision and common goals.

2. Architect and a builder, not just another player

New-age business analysts must be able to look beyond the near term goals and benefits. They must have a really good and long term vision to not only lead themselves but also the team members and the organisation, at large. They must think far and beyond, using their rich experience, in-depth and specialised domain expertise. The added advantage is that these help the analysts with a “peripheral vision” around the markets, business domains, products, processes and technologies.  Besides, the new-age analyst adds great value by laying a robust roadmap that is flexible, scalable, high-performing.

3. A soldier, well-equipped and prepared

Like a soldier, who is well-equipped and well-prepared to face any kind of challenges, the new-age analyst must be prepared with all the right tools, methods and a positive attitude. The very nature and aptitude of business analysts help them to stay on the top of their game, be it at home or outside their turf. Their ability to adapt easily and quickly depending on the situation helps build on to the agility of the new-age analysts.  Analysts’ skills of being sensitive, scrupulous and open-minded, help them usable insights from ideas and actionable intelligence from information. In addition to these, the BAs try to keep ahead by addressing all possible scenarios, potential challenges and constraints, internal and external dependencies and assumptions – stated and implicit.

4. Team player, not just a one-person show

Business analysts over the ages had been looked at more as specialised consultants who come in, do their work and get out. The contribution of analysts is considered from the prism of a “support” role who comes in early in the project, find problems, specify scope and requirements and exits the scenario. However, with the advent of agile practices such as Scrum, user stories, XP, BDD and TDD being put in place, organisations are increasingly looking for analysts to be well-integrated into the development teams. The analysts today are very much an integral part of the teams and by being  participative, they contribute to the collective value delivered by the team. So, new-age analysts are equally adept at being followers and team members themselves as much as they excel at leading the teams.

I hope this post helped you understand the many dimensions, skills and demands of the new-age business analyst. We will cover more specific details on the tools, and methods for the business analyst/product owner in the upcoming posts, until then, ciao!

Agile Development, Business Analysis, Information Technology, Product Development, Requirements Development, User Analysis, User Experience, User Stories

Gone are the days when you had professionals relying on the accumulation of knowledge alone. In this day and age of continual changes in technology, business, career and life styles,  there is an increasing emphasis not just on acquiring knowledge, but also on applying the experience and rich expertise. The focus has shifted from knowing to doing and sharing, from information gathering to using the right tools and methods and from just quantitative measures to insightful analytics. Like all other professions, this paradigm shift is quite apparent to a large extent in business analysis and product management areas too. In this post, I will touch upon the many facets that make up the emerging avatar of the new-age business analyst/product owner.

Many facets of the modern BA/ProductOwner

The traditional business analyst’s focus pretty much hovered on the requirements, documentation, functionality of the product. Also, the key lookout for the traditional BA has been one centred around the problem space, whether it has to do with the product, process, domain or business. The new-age business analyst’s core competencies are still based on the problem space and functional areas, their scope of influence has expanded further and beyond. This is thanks partly due to the continual changes in business, technology, ways of work and life. It could also be attributed to the “survival-of-the-fittest” theory and that the business analysts have to consistently re-invent themselves to keep them relevant to the changing and demanding times. New age_BUSINESS_ANALYSIS_Texavi_NBA

Realm and reach of the new-age BA

So what makes the new-age business analyst different from that of the traditional role? Interestingly, one school of thought identifies the BA as just another team player, there is quite another emergent thinking that is pitching the BA as a more responsible, leadership-oriented professional. From a mere documentation specialist, the realm and reach of the Business Analyst of today scaled up to that of the product owner and/or product manager. While functionality and features, problems and opportunities remain relevant and current to the new-age BA, the additional roles of release management, process improvement, increased customer and user engagement added a new dimension.

What make up a new-age BA/PO

Now let us try and assess the factors that make up a class act new-age Business Analyst. On the one hand, you need to be on the top of the product, process, business or domain, on the other hand you must also be able to connect well with “people”. A new age business analyst works her way very well through not just the product or process team members, but also key stakeholders, customers and users. Yes, it is true that the BA must be versatile and equipped with generic skills, it is beyond doubt that specialism and in-depth expertise add to the winning factors. In a nut shell, the new-age Business Analyst/Product Owner is versatile, agile, tech-savvy, responsive, responsible, and a leading-edge visionary.

In the next posts, we will look in detail the approach, tools and methods that shape up the new-age Business Analyst. Hope this post gives you enough food for thought till then. Until next, ciao!

Agile Development, Behavior Modeling & Design, Business Analysis, Information Technology, Product Development, Requirements Development, User Experience

Ever since the role of Business Analyst came into being, they have been associated with one specific area more than anything else. That is requirements and over the last four decades or so, the words analysts and analysis  have become synonymous with requirements.  In a traditional project or product development context,one of the frequently asked questions for a Business Analyst undoubtedly  is “Where are the requirements?”. However, in the recent times of agile methodologies and lean processes, like all other roles in technology and business, BAs too have had a significant makeover. In this post, I will touch upon this transition and look at the all powerful tool kit of the new age business analysts.

Texavi_NBA_Transformation

Business Analyst as the owner of requirements 

BAs traditionally had been responsible primarily for requirements in a product development or project execution scenario. Even though the role of business analyst involves right from the pre-sales stage all the way through to the project delivery, their focus area had always been scoping and requirements areas. BAs traditionally had their mainstay contribution to the product/project starting with requirements gathering, and then specifying and documenting requirements and communicating them to the stakeholders ranging from the management to the team members and from customers to the end-users.

Not just requirements in terms of the functionality, the influence and focus areas of the analyst could well be extended to some of the adjacent areas. Besides requirements, the reach of the BA would still be restricted to the peripheral aspects such as vision, scope and roadmap for the product, system, process or business in question. BAs have been made the masters and owners of requirements. This has been the case with the various roles, forms and names of the business analyst – be it a business consultant, product specialist, functional consultant or a domain expert.

Traditional meaning and scope of requirements

 So, what exactly do I mean by requirements in the traditional sense of the business analyst’s focus? Let me clarify this very important point with some examples. Requirements traditionally meant the long list of documents that ran into hundreds and thousands of pages. Some were called as Business Requirements Documents (BRD) while some others were referred to in the eighties and nineties as System Requirements Specifications (SRS) during the time of SSAD (Structured Systems Analysis and Design) times. As we moved slowly into the software analysis and development, the focus of the BAs slowly shifted into writing Functional Requirements Specification (FRS) and Software Requirements Specification (SRS) documents. You can notice that its just a change of the name, however the perspective, work and the output of the analysts still remained the same.

NBA_Texavi_Blog_31Jan2014

New age BA goes beyond documentation

In the age and times that we now live in, virtually everyone and everything  is going digital, mobile, agile and social. Like all other professions and roles which have undergone a huge shift, BAs too have had a significant change, after a really long time. The actual transformation in the role, responsibilities and contribution of the analysts came with the introduction of agile development methodologies like SCRUM, BDD (Behaviour Driven Development) and User Stories.  As we started implementing more and more agile and lean methodologies in the businesses, products and projects, the role of the business analysts has a far reaching impact on how the end products or processes shape up.

Texavi on the NBA requirements and communication

Today’s analysts need to move beyond the realms of requirements area and become more versatile and tech-savvy. All the way from interactions with key stakeholders through to the time the product or process has been delivered, the new age BA has to actually work with the team members. Analysts have to actively engage with various people involved in the project, product, process or business context and work alongside them analyse, design, develop, deliver and continually enhance the solution. This means that the analysts have to now create various artefacts such as the product backlog, user stories, wireframes, domain models, solutions models, prototypes and test cases, to name a few. I will discuss the details  of how the new age business analyst creates and works with these more effectively, in a separate post.

Hope you found the post useful – like always, please feel free to drop in with your valuable feedback. Until next post, ciao!

 

 

Agile Development, Business Analysis, Information Technology, Innovation, Product Development, Requirements Development, User Experience, User Stories

Often times this thought come across to me as to what makes people choose their professions. Is it their interest, aptitude, passion or simply demand in the market? I think its not just one of these but a combination of all of these that make up the professionals that we are all today. From a doctor to an engineer, from an entrepreneur to a scientist, everyone has a choice to make and that pretty much defines how they get set into what they do as their career. Looking closely at an analyst or rather more appropriately a Business Analyst, its amply clear that the role does have specific requirements, demands and expectations. Not everyone would like to be a Business Analyst and not everyone would be a good Business Analyst. So, what is it that makes one a suitable New-Age Business Analyst? In this post, let us look at some of the key factors, skills and attitudes that are the qualities of the New-Age Business Analyst.

Business Analysis is an art and a science

Yes, its indeed the most under-stated fact that business analysis is both an art as well as science. One needs to have the flair for analysis, reasoning, communication, identifying problems and facilitating in creation of solutions. A good business analyst is passionate, enthusiastic and a continuous learner. On the other hand, there is also no denying the fact that to be a a better business analyst, you need to learn the right tools and techniques to hone your analysis skills. From the SWOT technique to various notations such as BPMN ( Business Process Modeling Notation) and UML ( Unified Modeling Language) almost everything can be learnt and mastered as a discipline on a scientific basis. I will touch upon the nuances of these tools, techniques and methods in the future posts.

The various avatars of a Business Analyst

First off, let us understand and define the various names, forms of a business analyst. From a business consultant to a product specialist and various other roles, business analysts have been known by different names. I have come across some roles such as Domain Expert and Functional Consultant too. You might notice that the Business Analyst as we know cut across different industries and verticals. This ranges from Banking, Manufacturing, Information Technology, to name a few. I give below a diagram which shows the numerous avatars of the Business Analyst. Though this is not comprehensive, it pretty well presents a picture to drive home the point that the Business Analyst comes in various packages – shapes, sizes, colours, names and forms. However, you will notice that the core work remains the same, which is what we will refer in the later sections of this post.

Identity of a BA

 

Focus Areas of a New-Age Business Analyst

The main areas that a new-age business analyst focuses on are Business, Product, People and Communication. Unlike the popular perception, it is not technology, nor projects that would interest a business analyst. As the name suggests Business is the paramount factor for a BA and up next is the product focus and product thinking. No business analysis is complete if it does not touch upon the people aspect. From customers, users and team members to stakeholders and management, business analyst has to cater to the various ‘people’ involved. And if you ask me to name that one thing that separates the New-Age Business Analysts from all other analysts, it is communication. I created the image below to represent the focus areas and priorities of the new-age business analyst.

Focus areas

You can notice that the following are the priorities for the new-age BA:

  • What and Why, over How
  • Problems over Solutions
  • Product over Project
  • Facilitation over Implementation

Hope this post helped you in understanding the basic skillsets of the new-age BA. We will discuss more on this in the upcoming posts on New-Age Business Analyst. Until next time, Ciao!

Agile Development, Business Analysis, Business Case, Information Technology, Product Development, Requirements Development, User Experience

With over a decade of experience working as a business analyst, I have been a staunch believer of the saying “once an analyst, always an analyst”. Being a business analyst for a significantly large part of my IT career, I often thought about the evolution and transformation of a Business Analyst through these years. Ever since the role of a Systems Analyst conceived in the late seventies, there have been numerous changes to the name, role, responsibilities, job description and others.

From the modest roots of being able to understand, specify and communicate the problems and requirements through to that of a product owner and a change agent, the role of business analyst has gone through significant shifts along the continuum. For the sake of simplicity, I wish to call the old age business analyst, a “traditional” one and I prefer to call the modern avatar as the “New Age” business analyst. In this post, let me bring out the main differences between these and in the process, present and unveil Texavi’s New Age Business Analyst.

 

Traditional Business Analyst

Besides many other activities, traditionally business analysts have been gathering, analysing and specifying the requirements of a product, system or application. That role was specifically considered as the “requirements” person in the team. Largely for the most part of the late 1980s and early 1990s, analysts used to be part of the support team rather than the development team. Eventually business analysts transformed themselves into customer-facing roles with business acumen and domain knowledge. Systems analysts slowly turned into business analysts with an emphasis on the functional knowledge and awareness about the business and markets at large.

Business analysts moved on from a mere support role, and slowly their contribution and the recognition therefrom, in the product development lifecycle was perceived to be at par with the other prominent roles like programmers and architects. This gave rise to a new version of the business analysts in the form of subject matter experts (SME). Also referred to as functional consultants and domain experts, these business analysts have been adept in their business areas. They possessed the right blend of industry experience and expertise, alongside a dash of  IT exposure. They used to be the professionals with vast experience in specific industry verticals such as banking, manufacturing, healthcare etc. Analysts in these times started going beyond requirements and contributing more value to the product, business, customers and users.

The evolution of New Age Business Analyst

The business analysts as we see today are increasingly more empowered, and influential compared to their traditional counter parts. This transformation has been rather more pronounced and visible more so in the last 6 years, with the advent of agile processes. Its an encouraging trend that several organisations in the IT industry have been embracing with open arms different agile methodologies such as SCRUM, TDD (test driven development), BDD (behaviour driven development) and user stories. Also the transformation has been augmented by newer ways of product development, technology revolution. Market dynamics added another dimension considering that speed-to-market has been the mantra for success for most businesses today. I give below my interpretation of this in the form of a diagram, to drive home the above points.

Texavi_NABA_NewAgeBusinessAnalyst_Key_Factors

Who is the New Age Business Analyst

I can say that the New Age Business Analyst is agile, responsive, responsible, tech-savvy and people-focused professional. They are no more restricted to requirements alone but are empowered to own the product roadmap. Though largely focused on problems space, new age business analyst facilitates the solutions by pro-actively engaging team members, management, customers, users and key stakeholders. The New age Business Analyst is neither an outsider, nor a mere consultant to find faults and present reports. They are very much part of the teams, organisation and provide timely inputs and insights through their expertise and experience. Not just advice, they jump in by rolling their sleeves and work along with the team members in addressing the problems, needs, thereby creating solutions that work for customers and users delivering a great experience. At the same time, the New Age Business Analysts strive to make the solutions commercially viable from a business standpoint.

Its with great pride and honour, I unveil the logo of Texavi’s New Age Business Analyst.

Texavi New Age Business Analyst_NABA_Final_Logo

 

 

Please keep a watch on more updates, posts, applications  and news about our new initiative titled as Texavi New Age Business Analyst. Thank you and have a nice weekend!

 

 

Behavior Modeling & Design, Business Analysis, Interaction Design, Product Development, Requirements Development, User Analysis, User Experience, User Studies, User-centered Design

“There is no Average Joe Bloggs” – reads the copy on the billboard advertisement of an insurance company. I couldn’t agree more with this, especially in the context of designing and developing new products for end users. No matter how much I like Statistics, we just cannot apply it to all things in our personal and professional lives. While its good to be number-savvy, we need to balance the quantitative with qualitative aspects, to get it right. More so in the case of product design and development, the “law of averages” doesn’t quite contribute to the successful product development. We are all familiar with the concept of user profiles and personas used in the design and development of products. These help a great deal in understanding the real needs and goals of your target audience. In this post, I will dwell on why designing for average users is a misconception and how we can make use of user profiles and personas in developing successful products.

All customers are not users

This is the biggest notion among my clients that customers are well, users of the products. Not always true! The good thing is that both customers and users are both people, the similarities end there.  I think that “Customers” is a favourite term for Marketers whereas Designers and User Experience professionals connect better with the term “Users”. Customers are the people who purchase your products and services, while consumers or users use these. In some cases or well, most cases customers and consumers are the same. As in the case of some daily use products, white goods, FMCG, customers and users are the same i.e., people who buy your products use them as well. But in the case of high-end products, enterprise applications and productivity solutions, buyers could be different from consumers. For instance, office supplies, financial services, technology products like computers etc., the people who pay are different from those who suggest. These in turn are different from the people who decide and yes, the people who actually use the products or services could be completely different from the above groups.

First, know your Users

Knowing your users is the most important step in the approach to developing great products. By knowing your users, I mean to say that you must understand the goals and needs of the users. This understanding will help you in shaping your product or service, make it more suitable and appealing for the users. You can’t just create a product in thin air and then retro-fit it to the benefit of some people. As they say, the most important question in any business is asking “whose needs is the idea/concept/product going to solve?” . Texavi’s Unified Experience Framework has a whole phase dedicated to help you get to this. The “Know the Needs of your Users” phase has all the tools, techniques and technologies to ensure that we understand the real needs of the users. These are often unwritten, untold, unexpressed and even unknown to the very users. So, its a big challenge to get to the real needs of the users.

Know the Needs of the Users - Texavi Unified Experience Framework

 

User profiling holds the key

It doesn’t make sense to design and develop your products for all the people in the whole world. There is a danger of missing out on most people, as they think it doesn’t suit their specific needs and goals. Also, on the extreme end, it doesn’t make sense to design your products for one or two users. This argument lends weight for some people to think the middle path and rely on the law of averages. So, they think that the best path is to design and develop for average user. But hold on, what is an average user? How can you get to that person and define the characteristics of average user? The answer to this question lies in the user profiles and personas. User profiles are essentially the characteristic grouping of users based on various properties, traits and behaviours. This doesn’t mean that you are defining an average user. Instead, you are trying to understand the essential aspects of your users.  Using the profiles and personas helps the team to have a common language of understanding. This not only helps them in having a good picture of the end users, but also gives them a great affinity to the users, because of the name, form and physical characteristics.

UserProfiles_Personas_Design

Personas – archetypes not stereotypes

You might have heard of the term “persona” used in the context of marketing, research and product design. A persona is a representative user from amongst the group, but does not point to one user from within the group. It is a powerful design tool that helps the design and development teams and client relate to the target audience. Persona is not a stereotype of the users, but rather an archetype from the user group. In a persona, you give a form, a name and a picture to the representative users, so that all the team members and concerned people can relate to that person more effectively and easily.

Persona - Texavi example

 

Benefits of user profiles and personas

While there are many benefits of using the user profiles and personas in the product development life cycle, I list below a few of them that really stand out.

  • Understand the real users who you should target from amongst the many people in the population
  • Help prioritise the target segments within the groups of people
  • Know the real needs and goals of the target audience
  • Support in connecting and relating to the real needs of the users
  • Design, develop the products in a more practical and pragmatic manner
  • Evaluate and test the products, keeping the real users in mind
  • Minimise the effort, time and cost of development and rework

Hope you agree with me now that the average user is a myth and acknowledge the power of profiles and personas. Please keep writing in with your suggestions and comments. Till the next post, ciao!

 

 

 

 

 

 

 

Agile Development, Business Analysis, Business Case, Information Technology, Product Development, Requirements Development

When I visited the National Gallery of Arts in Washington D.C., one thing that struck me among all others, was a fridge-magnet in the display. It bears a popular saying of the great artist, Romare Bearden, that reads…”what you don’t need is as important as what you do need”. This caption has relevance to everybody in today’s world, and especially I would like to draw its benefit to the product managers.  I give below a snapshot of the magnet for your reference and I think it could be a powerful mantra for the product managers among us.

Get your priorities right

Getting your priorities right will not only help you to be successful at creating a great product, but also in continually delivering superior experiences to your stakeholders, customers and users. As a product manager, you need to not just prioritize the product’s features, but also plan your product releases, expedite the time-to-market, and help in marketing activities such as product launch campaigns. In this post, I wish to touch upon the challenges that constrain the proper scoping of a product, and how you can leverage the right tools and techniques to help prioritize in the constantly changing world.

Prioritizing is not easy

Today, more than ever, we are witnessing flux everywhere and little wonder then that whatever we are exposed to has been undergoing a rapid change. Change and chaos are posing the biggest challenge to all of us today, but in them also lie huge opportunities and avenues for achievement, cheer and success. The key to success lies in making note of the changes that happened and also in sensing the impending changes to come through in the areas of your interest.

What drives your prioritization

To come to grips with the changes and chaos, you really need to look at the various factors that are either directly or indirectly responsible for your product. Let us try and basket them into two categories- internal and external, for simplicity’s sake.  To be able to prioritize better, you need to consider the internal factors such as the resources available say people, schedule, cost, organizational goals and business vision. I would also like to add to this list the often unseen or unspoken aspects such as internal politics, power dynamics and the relationships among the various management and team members.

Vendors, partners and third party service providers

Also you need to pay heed to external factors such as stakeholders i.e., vendors and partners’ expectations, needs and demands of customers and users. While its true that customers and users’s needs take the attention of product management team, its also imperative that the capabilities, constraints and commitments of your vendors and partners need to be considered while planning and prioritizing your product.

A case in point is Apple’s inability to fulfill its iPad2 delivery requirements in some countries. This was due to the shortage of material at Apple’s suppliers in China which resulted in the delay in shipment of the final products. One might argue that this is a good problem to have because the demand is more than the supply and you can keep your customers wait for your product. On the other hand, there might be a worst case scenario where the supply exceeds the demand and then you will be in trouble with the excess stock. In both cases though, the lesson for you is to consider your vendors’ and partners’  constraints, capabilities and commitments while prioritizing and planning your product release.

Beware of (pressure due to) competition

Perhaps the one biggest factor that could play with your prioritization game is competition. Often times, as product managers, you get undue pressure to look out at the competing products in the market and re-adjust your priorities as per your competitors’ new releases.

For instance, just because your closest competitor announced (not even launched) a new product in the market, you will get tremendous pressure for ‘doing something about it’ from the senior management, peers, media and worst of all, your own team. While most often, all of this could be genuine and help in the cause of better product development, other times, it could be a knee-jerk reaction without knowing the ground reality. This is something you must be really wary of and ensure that you don’t succumb to the pressures beyond the capability of your organization and team.

Scope, de-scope and re-scope

The single biggest contribution from a product manager, if you ask me, is the ability to prioritize the features and plan the releases for the product. This is the area where team really looks up to the product manager or product owner in the context of agile software development. Prioritization, as per my experience, comprises three simple tasks of scoping, de-scoping and re-scoping. As I keep telling people, sometimes it is more important to specify what is not in scope, than to say what is in the scope.

In a traditional sense, you might be maintaining a ‘product roadmap’ which spells out all the things your product will be and do, in the times to come. In agile development, product owners need to maintain a ‘product backlog’ which is a configurable document that lives across the life-cycle of the product. For some people, the term ‘backlog’ might connote a negative intent of not being able to complete some stipulated work. But now the artifact as well as this term has become an industry-standard accepted by many. Remember, though that this product backlog is for the product and not, as many people mistake it, for the project.

Important vs. Urgent

Another key dimension in prioritizing is being able to specify either tasks or things on the scales of importance and urgency. Note that all things that are important need not be urgent and vice versa. You need to clearly delineate among things and tasks that are important, urgent or both.

I usually map all the items across four quadrants classified into the following four categories across the two axes of importance and urgency:

  1. [important, urgent]
  2. [important, not urgent]
  3. [not important, not urgent]
  4. [not important, urgent]

Use the right tools and techniques

Most of you are familiar with the prioritization techniques such as ABC or 1-2-3. You can also try the MoSCoW (Must, Should, Could and Won’t) technique which is helpful in further shortlisting the features. I use index cards and post-it notes to do a quick sorting from within the shortlisted features to get to the most important ones. At times, to simplify you might just mark the items ‘Need to have’ and ‘Nice-to-have’. You can use any, all or some of these techniques based on your preference to arrive at the prioritized list of features in your product.

We can talk about more such tools and techniques in my next blog posts. Hope you could have some takeaways from this post to help make your product, a success. Till the next post, ciao!

 

 

Agile Development, Business Analysis, Information Technology, Requirements Development, User Analysis, User Experience

People all over the world celebrated the onset of new year 2011 with fun, aspirations and resolutions. This cheer and  high-spirited enthusiasm continued well into the first week of the new year.  However for some people, the early days of the new year proved not all that fun. They got up later than usual, reported late, missed their appointments and meetings. You might want to blame all this mayhem caused due to the hangover and the high-spirited celebrations :). Well, that was not the true reason. The real culprit was the mobile phone they were using. Yes, it was Apple iPhone4 that these people have been using that created the problem.  The Alarm app of the iPhone4 failed and did not set off (or is it ‘set on’ ? ) the alarm.

Small problem, big pain

You might say that this is just one small problem for a few users which happened, one day. After all alarm is just one small app in iPhone and it did not work on one day and so, its really not a big deal. I agree, but then think about the consequences of this small bug and the inconvenience it caused to the users. Even a small defect in the product could become pricking one to users. I remember my good-old Hero Honda CBZ,  first version which I bought in 2001. It was a brilliant motor bike with a fantastic performance and great looks. I was really happy with it except one small itchy glitch. Look at the images below and you can guess what the problem with this motor bike could be.

Its not all about look and feel

Yes, you got it right. The problem was with the placement of  kick-rod and footrest in this model of CBZ. Footrest was placed right below and would stop the kick rod from going down. Since there was no electronic auto-ignition, starting the motor cycle requires three steps…

  1. Take the footrest up, so that it doesn’t come in the way of kick-rod
  2. Kick the rod down so that mo-bike gets started
  3. Immediately get the footrest down, for applying breaks

Phew…so much pain just to start a mo-bike. Just imagine your plight when in the midst of heavy traffic on a busy road, the CBZ stops and you need to start it in a split-second, else you might incur the wrath of a 100 horns blazing all at once. The curses and prayers of many a user like me, would have reached the people who matter at the motor cycle company. In the newer version of the CBZ, Hero Honda introduced is an electronic-ignition. So, the moral of the story is ‘all looks and no work makes your product a flop and users irate’.

Go beyond the briefing, but first get the basics right

The above problems have nothing to do with lack of user experience, or delight factors. They refer to the breakdown of a simple and basic functionality of the product. Nowadays in a bid to get quicker and closer to customers, product companies have been getting on to the bandwagon of offering delight to their users. They have been treading past the drawn lines, going beyond the briefing. I fully support their intent and actions and also believe in the end results of their efforts, which is better products and happy users. However, this is not completely hunky dory and in a few cases, companies do not realize that they are committing some basic errors. To attract their users, the product companies are forgetting that their products must first work well and satisfy the immediate needs of their users.  There is an imminent need to realize that ignoring this might lead to frustrated users who will shun using their products and services.

It does not really matter if your product offers great bells andwhistles, while at the same time it cannot provide the core  functions. Often, in the name of user experience, product owners do tend to overly focus on the presentation losing sight of the other important factors such as functionality, navigation and interaction. As Steve Jobs rightly puts it, “Design is not what it looks like and feels like, Design is how it works”. A case in point is the call dropping functionality of iPhone4. Not too long back, you might recollect the problems reported with the dropping of calls in iPhone4. This issue was more noticed when users holding their iPhone in left hand at a particular angle.  Apple accepted the that there was indeed a defect with the phone’s antenna placement and offered a bumper cover free to the users.


In case you are wondering why I am riling Apple only all along, well it is not alone in getting the bad campaign.  Hotmail recently joined the shame game when most of its users, one fine morning, found their mail boxes empty, all of a sudden. Some other users found a few mails missing. A few others were annoyed to note that some emails were lost. I guess you would agree that the basic purpose of an email product is to receive and send mails. If this very primary functionality is not in place, don’t you think it raises alarm with the users? Of course, not only do they stop using the  product, but they spread the bad word pretty quick. So, address the  important things first in your products, services or processes…functionality, those that matter the most to your users and you too.

Form follows Function

There has  been an eternal debate in the design circles about the seemingly conflicting approaches of ‘Function follows form‘ and ‘form follows function‘.  My ‘Business Systems Analyst’ background gets the better of me and I support the latter option, i.e., ‘Form follows function’ theory. Of course, I don’t apply this to all and sundry. Leave alone some specific products like art works, paintings, craft and decorative items etc.,  which definitely have a dire need to look prettier first, as that is their core objective. However, for the rest of the other products which we use in our everyday life and work, functionality should be the first goal followed by the looks. Often times, the way a product has been designed, especially the aesthetic appeal  accentuate the function and make it better.

FURPS and You

Functionality scores over pure-play user interface and mere looks. So much so that the good old model, FURPS which classifies the software quality attributes, function places Functionality on the top much before other factors. For starters, FURPS refers to Functionality, Usability, Reliability, Performance and Supportability. There had been additions to this list, what is being referred to as FURPS+.  The + or extra attributes are interface, implementation, operations, packaging, legal etc. Irrespective of whatever gets added to this list, one thing is pretty clear… that functionality always precedes everything else. So, in case you ever doubted what the Business/Systems Analyst in your team does, you have an answer now.

Focus on the WHAT

I doubt how many times you would have lifted the bonnet of your car to see what’s inside. Compare this with driving your car using the steering wheel, gears, clutch and other parts in the car nearby to  the Driver’s seat.  Not many users (barring a few, such as technicians and mechanics ) would wonder how your product is working. What matters to most of them (the normal users, barring advanced and expert users) is that the product should work and do the things it is supposed to do, in the first place. From a Software Development Life cycle (SDLC) perspective, Requirements always come first before Design and Development. Even in this age of Agile development with SCRUM, Extreme Programming and User Stories, you still need to understand the ‘WHAT is to be done’ before you proceed with ‘HOW it is to be implemented’ . First, focus in understanding WHAT is required of the stakeholders, and users from the product or application that you are developing.

Make the functionality clear

Its not only important that you focus on getting the functionality right, but more importantly you need to make it clear to the user what are the things they can do with your product.

Design and develop your products and services in a way that users should understand what they can do with the products or services.  If it is not clear to your users as to what your product offers to them they will eventually dump it. For instance, Google Wave failed big time because it was not clear to the users what they could do with it and how it would help them  any better than the existing lot of the social networking and collaborative platforms. Also, iPad had a few takers initially in the first few days, as some people had questions about what exactly it offers. They could not see the real difference between iPhone and iPad, sans the ability to call. Some even called the iPad a glorified and bigger format of iPhone.


To conclude this post, all I have to say is that, as developer of products or services,  you need to set your eyes and mind first on the functionality. If it does not work, they will not use it!