Product or Internal System why it is important to make a distinction

When do you need a BA and when do you need a Product manager? why is it critical to get it right?
Whenever I write about anything connected to product development or systems implementation, I am acutely aware of the amount of critically important stuff that I have to gloss over or ignore in order to stay readable and this is no exception.

In broad terms, it is very easy to make a distinction between a product and an internal system. The internal system is being rolled out to the workforce and there is not normally much option about whether it can be adopted and used by the target audience, that is, unless it fails to deliver.
The product, on the other hand has to be launched to a public audience who must be sufficiently convinced that it meets a compelling need or solves a pressing problem, to part with their cash and use the product.

There’s a world of difference between investigating a business problem, creating a business case and designing a solution to this problem and identifying a market sized need, establishing a product problem and designing a compelling solution with confidence that you will have a success on your hands.
The stages we go through are remarkably similar and almost interchangeable, but the big difference is in how we engineer and verify requirements.

Although many products begin as an idea in the mind of a director and are driven forward by this vision, at some point a professional product manager has to establish a strategy for verifying these requirements with the intended purchasers and developing a compelling value proposition that will sell the product.
Faced with defining requirements that will motivate users to pay for your new product, you will need a lot of new consultation and communication techniques that are generally well beyond the scope of a Business Analyst, you will also need deep knowledge of the marketplace to assess not only how well your product may be received, but how the competition will compare and how they will react to your offering.

It is remarkable how often this fundamental truth is ignored by government and public agencies who believe or assume that they have a captive audience for their brainwave, when in fact the public often remain unimpressed and find alternatives or ignore it altogether. A simple product management methodology and the use of more appropriate skill sets could save many of the costly blunders in e-government and deliver dramatically more benefits for most of the remainder.

Ed Taaffe

A Bridger or a BA how do I choose?

At first glance it may seem that there is little difference between a BA and a Bridger.
First off, it is important to realise that there is more than one flavour of BA and end also more than one flavour of Bridger so every opinion is completely valid. Additionally it is likely that a Bridger will also be an experienced BA or Product manager and some BAs will, knowingly or not, be Bridgers.
In principal I do think it is easy enough to draw some clear comparisons that differentiate the Bridger form the BA.

  1. The profession of BA within the world of IT systems and process automation has evolved almost entirely form the IT profession as opposed to from the Business . Even with a large number of Universities now producing Business Analysts, this has changed little and the curriculum is heavily flavoured with IT as opposed to business. These BAs are really much closer to requirement engineers than Business Analysts in my view.
  2. The BA almost always operates as part of an IT lead project and under the leadership of a Project manager employed by the IT department or indeed by the external system supplier.
  3. The BA is invariably an analyst by nature, extremely oriented towards process, mathematics and systems as opposed to being business savvy, intuitive or people oriented.
  4. The Bridger is an experienced business person with a business training and an ability to empathise with business managers, to understand and champion their concerns and to help them find business solutions.
  5. The Bridger is a people person with experience and knowledge of human motivation and the fundamentals of behavioural change within an organisation and as such is able to define solutions with an eye to their impacts at an organisational level and the likelihood of their enthusiastic and successful adoption
  6. The Bridger also has training in IT and sufficient understanding of what is possible to be able to translate between the language of systems and the language of Business.
  7. So when should you use a Bridger instead of a BA?

    When you are approaching a project that you intuitively expect to meet with a level of resistance within the business, it is critical that you choose someone with a heightened awareness of change management issues. Much of the potential risk can be eliminated at the business process or requirements engineering stages as opposed to surfacing on launch day. Requirements engineering can and should be used as a tool to communicate the rationale and potential impacts of change and to build in a degree of acceptance early on.

    When you have complex business problems to solve that require more than just basic process engineering to resolve it and requires the continual engagement of senior stakeholders both as contributors and accepters.

    When you have a history of conflicts between IT and the business in terms of IT investments it can be beneficial to have an arbitrator and fixer who can understand both sides of the argument, present them effectively to the other side and gain critical agreements that allow for progress to be made.

    When you want to understand how technology can deliver competitive advantage as opposed to which is the marginally better technical architecture.

Managing requirement scope

Sometimes the definition of requirements and management of their delivery is described as Scope management.  Scope management is composed of five distinct phases:

  1. Scope initiation
  2. Scope planning
  3. Scope definition
  4. Scope verification
  5. Scope change control

Scope initiation refers to the justification phase. This is when a Product management team create Market requirements and Product requirements documents or a  corporate change team will create a Project mandate and produce a Feasibility study.  It is high level, but it is critical to establish clearly that there is a need or justification and to understand the early boundaries.

Scope Planning is a lot more than it sounds and the danger in glib descriptions like this one is that they can easily lead to not taking the work seriously enough.  This is the time when the established high level need at strategic level or market level is translated into a clear product definition with features that hopefully trace right back to the benfits put forward in the outline business case.
This phase is where the real requirements engineering happens and where the product  design ideation and design phase product development will happen.

You may well be sitting there saying yes, but I only wrote down requirements for a simple off the shelf system and purchased it. Well if that was the case, going through the motions of making sure you understood the  benefits and that the product would really be able to deliver them will have been quick and easy.
 In my personal experience, the purchase of a cheap printer can be fraught with problems unless you go out with a clear scope in mind.

Scope definition.

This is where you either define work packages for the various teams of developers or suppliers, or you place and manage a procurement contract.  Without a sound plan and careful management, the best possible plans and designs can come apart very quickly at this stage as requirements are misinterpreted, deliverables fail to deliver and tests fail to impress.

Scope verification.

This is best started at the earliest possible time. Ideally it starts as soon as there is a single deliverable that can be tested alone.  This is the process of verifying that the deliverable performs, that it meets performance specifications and finally that the end product is capable of delivering the benefits.

Scope management.

This is another part of the project that can continue right through the process. It is the positive act of keeping  everything form the earliest designs to the final deliverables within the scope that was agreed and signed-off and just occasionally invoking a change request procedure to accommodate a truly great idea or a serious oversight.

These five activities applied judiciously to the definition and delivery of a product of any kind will greatly increase the likelihood of success and reduce the risk of failures.

Ed Taaffe


Design Phase Product Development

Don’t let the creative urge design a Hummer when your customer is asking for a bike.

What you are designing is a space in the mind of your customer which is perceived as real value for their money and or emotional gain and the marketing input is as important for value creation as the technical.

Design phase product development is the part where most organisations are reasonably competent. Whether they are developing engineering, health-care, software or other products, they tend to have many people who are expert in their field and there is generally an appetite for late nights in the lab or prototyping space or wherever the creative process is happening.

Sometimes, even when the product design ideation has presented a palette of ideas and filtered them down to a set of requirements, some of the best organisations then loose the plot entirely and begin to design products in isolation from commercialisation, stakeholder requirement,, strategy, MOC or any of the guiding influences which are there to make the job easier and more successful. This is a fatal mistake.
Before you even consider any design efforts beyond basic technical feasibility of high level ideas, it us critical that you have a palette of requirements to begin with and that you know with a reasonable level of confidence how much value your customers place on each of these requirements<!–[if !supportAnnotations]–>.

So now that you are ready to begin the design work, you should have a number of key goals in mind:


  1. The need to create a product, which combines a number of the given requirements to deliver maximum value to the customer for price.
  2. Need to create a product which poses the minimum level of risk either technological, political, regulatory or otherwise unless this is specifically agreed in advance.
  3. Need to test prototypes at every stage from basic drawing to beta with real users (not your spouses or best friends)
  4. The need to understand the emotional drivers that will win or lose the sale for your product.

Remember, a lot of research has already gone into this and a lot of decisions have already been made. I would never suggest that the process should be so rigid as to ignore a great idea at any stage, but in the interest of Time to Market, there can be little justification for rambling away from the requirements list at this point. Neither is there justification for taking unnecessary risk technologically unless enormous potential gain can be sufficient to justify the risk and it is agreed at a high level.

It is also useful to bear in mind that there is always more than one good solution to any problem and there is usually no sure way of picking the best one, so once you get to the point where you have a number of potential combinations which would deliver your product JFDI Just *ing do it. Pick the best one and get on with it.

It is important to bear in mind that design phase product development is neither the beginning nor the end of design because it really began with involvement of engineers at early ideation stage and will continue until all of the marketing collateral is created and tested.

So what is the conclusion?

Design begins at the research and goes on long after launch.

Design phase product development involves marketing and publicity people who can help create value.

Design phase Product development should begin with a palette of requirements that can be met be met by a set of features optimized to deliver maximum value for minimum cost and match a predefined positioning requirement.

Ed Taaffe

Write software requirements specification

Since the Dotcom boom we have all come to know and love them. Their USP is: “One eyed man in the land of the blind” their value proposition is” I won’t blind you with science because I don’t understand it myself”. Yes they are the product managers of the software world, the IT directors, the Gadget Barons. Luckily for us they know what we want before we do. They will tell you that requirement engineering is for Nimbies and that suggestions from users are too dumb to take seriously. Allowing a mere human to write software requirements specification is not something they would easily consider.

I suspect that GBs also exist in the white goods arena. I have no idea what all the buttons and programs on my microwave or washing machine are for. The GBs also are firmly ensconced in my supermarket, where I pay for two loaves and take one because I can’t eat two and these gurus are convinced that selling me two at a discount will make me happier. Perhaps they are thinking of the sales of exercise bikes after all the overindulgence, or maybe they themselves eat a lot of bread.

We read with horror that 80% of government projects fail, but can you believe that in the hard bitten commercial world almost as many new product launches also fail. If you don’t, then you haven’t been paying attention.
Microsoft claimed recently that the majority of new feature suggestions from users were actually for features that already exist. Surely this tells you something about communication with users. What’s the betting that these features were included in response to user need?
Ok, now we’ve touched on one of the buzzwords and our world will never be the same again. Why should we build products that are user focused? Dumb question I agree, but this message still has not made it’s way through to 80% of the marketing world and possibly 99% of the software world. I believe I know a little about why this problem persists. You see there is a unique relationship between a product, its users and it’s stakeholders. I describe this as the UPS Triangle™. User- Product-Stakeholder.

The ultimate driver here is the stakeholder which is often a board of directors, and shareholders, or in political terms it is senior civil servants, ministers and citizens. Products can’t begin with user demand as the nice diagrams would suggest. Henry Ford never had a deputation of frustrated horse-riders turn up and demand he invent a motor car. This is why the GBs have a real part to play, they are the visionaries willing to spot a potential opportunity and pull together the support and finance to explore it and to make it happen. The people who provide the finance and take the risk are the people who want and deserve the reward and this is what makes them stakeholders.

Here however, lies the twist. To deliver this reward users have to agree that your product gives them value and become customers. That’s why it is a mutually dependent triangle. The confusion domes when the Product manager loses sight of this triangle and agrees to satisfy the stakeholder directly, hence ignoring the user and ultimately failing to deliver a successful product. On the other the side of the equation, if you leave product development to salespeople they will give away everything to the customer forgetting about profit and lifecycle management.

You can’t have much of a conversation with a marketing type without stumbling across the term “perceived value”.(PV) What they are referring to here is the “reason to buy your product”. Just think of it as another currency. The more of this PV you give to your customer the more of their currency they will be happy to give to you. That’s the ten second MBA, all you ever need to know about business. (link to value creation blog)

The profit is in the P. That’s right you see perceived value is in the mind therefore it can be created relatively cheaply and maintained even more cheaply, whereas products have to be manufactured packaged and delivered and depend on supplies of other commodities. E.G. A Ferrari costs much the same to make as a Jaguar, but it sells for immensely more, because it’s PV is such that wealthy men will gladly part with buckets full of wedge just to be seen driving one.

In this case, which is likely to be more important? what users want you to deliver or what stakeholders want you to deliver. Whose perception is likely to drive product sales, the stake-holder’s or the user’s.

So what is the concluson?

The Gadget Barons are annoying but they are also necessary. Users perceptions is where the gold lies. Perceived Value (PV) is where the profit is made. The more PV we can offer in our product the more £ the customer will be willing to pay.

The first rule of product development is to manage the UPS triangle and reward stakeholders by maximising PV to the customer. If you want to write software requirements specification which will lead to winning products then you must forge and maintain the right balance between Stakeholders, users and technologists.

Ed Taaffe

The Bridger

“Bridger” A person who acts as go between or translator between the management of a business and it’s IT department or IT partners.

The background

Since the arrival of computers in the enterprise there has been an unfortunate and counterproductive power struggle between IT departments and other areas of the business.
IT professionals share a great deal with other professions such as law and medicine in that they have their own impenetrable language, they are critically important to their clients and they simply can not be substituted with amateurs.

The difference between IT and other professions is that systems and IT tools, especially systems are right at the heart of the every day operations of the business and a fundamental part of every aspect of the business operations.

Naturally it is a source of very serious concern for business that such a critical function as IT is managed by people who are more often than not detached from the business functions and often lack very much understanding or training in business issues.

The key problems faced by a Bridger

Problem one – The Business versus the IT department

In order to create and maintain a competitive advantage for the enterprise it is essential to combine deep understanding of the business, enlightened leadership and a thorough grasp of what IT can achieve.
The business leadership are custodians of business strategy and direction and hold the deep understanding of the business.
The IT department or partners hold the deep knowledge of how existing systems work, the impact of changes to them and what new technology is capable of.

Almost without exception, the two areas create and maintain their own plans and strategies in isolation and believe at some level that they can exist successfully in silos. This standoff when it occurs to any degree, is destructive and robs industry of billions annually in lost opportunities and wastage, mostly surfaced as failed projects.

How the Bridger can help

In the short term, a Bridger can mediate between IT and the business translating between IT and Business language and negotiating win/win agreements.
In particular the business needs to understand impacts and costs of sudden demands for change on the IT infrastructure.
The IT department needs understand clearly the real life drivers that have potential to place unwanted demands in their inbox unexpectedly. Speaking both languages and understanding the underlying problems on both sides makes the Bridger ideally paced to forge this understanding.

In the medium to long term, a Bridger can help forge an understanding by helping to establish sustainable frameworks that see joint plans and strategies developed by the business and IT jointly to forge new partnerships in place of the silos or misunderstandings.

Problem 2 – Business analysts are trained in IT

The most important element of every software project is what it delivers to the business. How clever the technology is, whether it was delivered a little early or late or slightly under or over budget, are all relatively unimportant in the grand scheme of things, but if the system fails to deliver value to the business, it will be a costly failure.

Whether or not the system delivers value is down to understanding the needs of the business, optimising processes for automation and implementing the accompanying cultural change to make it work. These are all business and people centric skills.

This critical job normally falls to a business analyst, but there lies the problem.

With a very few exceptions, business analysts are not trained in business analysis or indeed in any other business discipline. The majority are programmers who went down the analysis route and see their role as designing systems and working with IT delivery. In recent years some have been emerging form universities with degrees in business analysis, but even then they are quickly sucked into the existing culture and still lack the business knowledge to understand the issues and the gravitas to engage senior management.

It’s hardly surprising then that there are frustrations, communication difficulties and disappointments as the enterprise attempts to manage its it investments.

The alternative to this business analyst route is when the business, in exasperation appoints someone from the business to gather requirements. This is an even bigger mistake because the non it person has no idea how to extract or record requirements or how to communicate them to IT people and especially he/she has little chance of monitoring the accuracy or quality of the deliverable.

Another very common error seen more and more in recent times is to react to this problem by appointing a non IT trained Project Manager to deal with the business and systems sides of the project. While business stakeholders may enjoy better communication in the short run, their holiday is generally short lives as this strategy lets IT off the hook and leads to a catalogue of poor decisions and a high proportion of failed software projects.
Government in particular are guilty of this mistake as they place too much trust in partners and maintain little, or often no internal skills and knowhow to oversee these huge projects.

How the Bridger can help

The Bridger is by nature a business person with the ability to explore, understand and improve processes as well as the training to explain and present them to the IT department, or to work in tandem with the IT department making sure that they get the business viewpoint right.

This approach ensures that the business goals are represented by the new proposed system and the level of change is understood and accepted by users so that a system can be designed and implemented with confidence.

Problem 3 – Stakeholders, Users and Technologists, the tradeoffs.

Stakeholders (define here as the people providing the investment and expecting the rewards in productivity) are all powerful within the project team and all things considered, this is how it should be.
Users, even for an in-house system, are still key. Unless you understand their needs and serve them, the system will not deliver value.

Technologists are the people who know how to deliver on your needs and to make it reliable. Nobody notices them when everything is running smoothly, only when it goes wrong so you can’t do it without their help and goodwill.

When it comes to defining the final feature set of a system, stakeholders will have a detached and uninformed view of what happens on the shop floor and will want to dictate how the system should be. If they get all own their way it will almost certainly be a disaster.

Users will resist change and will not want any new system so their feedback important as though it is must be understood in context and then interpreted at the right level to deliver achievable changes.

IT will want to dictate the system based on what fits comfortably with that they already have and will have no empathy with users or stakeholders.

How the Bridger can help

The Bridger can help by forging and maintaining the right flows of communication between IT, Users and Business so that ultimately the Business gets what they want through ensuring that IT works with the User to maximise process and pitch cultural changes at a level that is achievable and lends itself to a successful implementation.

Ed Taaffe