If you have ever built a new product that couldn’t
be sold by your sales force, this class is for you. If you have defined a product that your sales force was already
having success selling, but which your engineering department was unable
to build, this class is for you.
This class is for hopeful engineers who want to
make sure that the fruits of their labor go on to benefit many users.
I’m tired of seeing hours of engineering time wasted building the wrong
product and useless features. I’m tired of software projects that are
cancelled because they are “out of control.”
I want engineers to have confidence when they start a project
that they will know when they are done, and that specs won’t change out
from under them. I bet you
do too. SWIFT can help.
This class is for frustrated product marketing people
who want to know how to tell engineers what to build. I’m depressed by detailed marketing requirements that result
in products with the right features but assembled in a useless way.
I grieve for the product managers who slaved over these requirements and
who are flabbergasted by the resulting product that comes out of engineering. I
cringe thinking of the abuse poured upon them by the sales force who can’t
understand how to sell this product against the latest new offering from a
competitor. I want to see this end.
SWIFT can help.
This class is
for the many overworked people in technical support who want to impact future
products so that they don’t become support nightmares.
Customers deserve better products and support engineers should not have
to face the frustration of customers who get hard to fathom products.
SWIFT can help.
This class is for suffering technical writers who are
tired of being asked to document a poorly defined feature to make it easier for
users to learn and use it, and it is for trainers who are frustrated that they
have to give training to cover poor designs.
All too often these people are expected to fix problems that date to
project inception and because they start work at the end of the life cycle and
are gating release they are given no time to do their work.
SWIFT can help
This class is for general managers, held accountable for
results, who are tired of hearing “there is never enough time to do it
right, but always enough time to do it over”. It is for people raising financing for projects who know that
they won’t get multiple trips to the plate to get it right.
If you are trying to be more successful in contributing
to the design new products and services in any of these roles.
This class is for you. Your
job is one of the hardest imaginable.
Because you are working on something new you can’t rely on existing evidence. And there are so many interdependencies between the idea for
a new product and its success in the marketplace. It takes a lot of good fortune
to succeed. It is no wonder that it
is said that “It is smarter to be lucky, than its lucky to be smart”.
Despite that component of luck, a lot of the problem is
really just complexity. It is hard
to know everything you need to know to be sure.
So you have to make choices. Where to focus. What do you NEED to know to move forward, and what would you
like to know, but are willing to guess at for now.
This class will help.
It is full of risk reduction strategies that will help you identify and
stay focused on the most important problems.
You may still choose to move forward without more information in one of
the areas covered here, but you’ll knowledgably make that choice, and you’ll
know what to watch for as symptoms that you choice poorly and should revisit
your choices. So this class may
make you smarter, and even though that won’t necessarily make you luckier, you
may be on path to helping to make your own luck.
What you will learn
With this class you’ll learn techniques that ensure that
once the product is done that you WILL be able to sell it, no matter what the
competition does. You’ll learn how
to arm your sales force to sell it.
You’ll learn how to define specs for the engineering department that
won’t change with every change in competitive offerings.
You’ll define specs that engineers know will address what you need.
And because they won’t change your engineering projects
will be done sooner. And they will
result in less code to write, less code to test in QA and less problems to
support in the field.
Your products will be perceived as easier to use and
delivering more value with less learning required.
You’ll be able to tell well in advance how good your
design is, and you’ll be able to verify that results you get in release meet
your original design requirements.
What is SWIFT?
What is SWIFT?
And how will it make it easier to design products and services that sell? And
can be built?
SWIFT is a cradle to grave approach to understanding why
people buy products and services, and taking that understanding and turning it
into requirements that engineers can build from and which will ensure that
customer’s needs will be met by the resulting products and services.
There are many steps along the way that allow you to gauge how well you
are doing, and the goal is to reduce risk and gain certainty before investing in
Of course, any step could be skipped or short-cut, at
concurrent increase in risk. However, in general this is not a good idea. Too
often this results in a development schedule that balloons out of control –
because developers don’t really know how to tell when they are really done.
Features and requirements shift and pop up at the last moment.
The result is bloated products that are too hard to use, are full of
buggy code that had to be written and tested and now has to be supported in the
field, but which wasn’t really necessary or even desirable to start with.
With SWIFT this doesn’t have to happen.
By the time you complete detailed design with SWIFT you’ll have an
effective acceptance test that both you and your developers can use to insure
that your goals have been met. This
is perfect if you want to outsource development, even to foreign development
teams. Because they know how to tell if they are successful they can
test at any time to see if there work is really done. And if they pass the test, you’ll be sure that it is done
Organization of SWIFT Courses
This class is divided into the following parts:
This is the section you are reading now.
It tells you what SWIFT is, and what it can do for you.
The 10 Step SWIFT Design Process
This is the main part of this class.
Each chapter covers one step in the ten step SWIFT process. For
convenience, I have grouped these into 3 major sections that group steps into
larger design and release processes. While work can proceed on several steps
simultaneously, there is a natural top down flow to the process and readers are
urged to read these chapters sequentially.
Additionally, there are a lot of relationships between results in one
step to work in other steps, and this will be much clearer if you read all of
The ten steps are:
This is the first of 3 phases of SWIFT. This first design
phase involves investigating who the key stakeholders are that need to be
influenced to make the product sell, what their goals are and what tasks they
are currently performing to achieve these goals. From this we posit our new
products or services and then compare how much faster, easier or more accurately
stakeholders are able to meet their goals with the new products or services.
This provides assurance that customers will be motivated to make their
purchases, regardless of what the competition is doing!
Identify the Stakeholders
In this section we discuss how to identify and
characterize all the stakeholders necessary to make a sale. We’ll learn how
important it is to create archetypal characterizations, and to identify key
roles people play and traits they have that influence their buying decisions.
Goal Oriented Design
In this section we discuss how to identify and categorize
goals. Goals are what provide
people’s motivation, including the motivation to change which products they are
using. We’ll see that there is a hierarchy of goals and that motivate more
powerfully than others. We’ll use
that in trying to find what goals to address in our designs.
Task Oriented Design
When people have goals they come up with tasks to perform
to address them. Sometimes they are
effective and sometimes they aren’t. What drives people to adopt a new product
or service is the reduction in effort, time saved, increased accuracy or
pleasure they get from the experience of using the new product or service
We’ll determine what they are doing today to figure out how good our
solution has to be. Then we’ll hypothesize our solutions and check that they are
sufficiently better to get people to switch.
We’ll also look at the effort involved in switching itself: learning
about the new offerings, acquiring it, and mastering it.
We’ll see how that affects adoption as well.
Now we have an overall idea of a hypothetical product or
service that we think will provide a better experience to the stake holders we
have identified. But before we build it, can we verify that it will be good
enough? Can we estimate more
accurately, and even quantitatively what benefits stakeholders will experience?
Can we define more precisely the features of the product so that
engineers can build them in a way that assures we will wind up with the overall
results we want? The Detail Design
section is a way to peel the onion and go increasingly deeper in our
understanding of the precise requirements we want to develop to.
We start by understanding the limitations of the human
processor that powers each of our stakeholders. We are good at some kinds of skills and poor at others.
We want to choose wisely so that we maximize what people are good at, and
limit requirements on them to do what people do poorly.
We evaluate these skills in terms of human memory,
reasoning, communication, perception and motor skills.
We see that there are techniques for estimating performance time and
accuracy for some of these skills, even before we build a prototype, thus giving
us confidence that our designs will provide the improved experience we posited
during task analysis.
Visual Representations Design
Taking into consideration what we learn about perception,
we can start to select visual representations
that are more compelling and clearer to stakeholders, thus ensuring that
they will have the desired experience.
At this point of time, we have some idea of what the
visual representations (the “look” or “appearance”) of our product or service.
We also have a defined a set of tasks or actions which are the behavior or
“feel” of our product.
With this in mind we can select among different kinds of pre-programed
user interface pieces, widgets, that might want to use in our designs.
In addition to look and feel of a user interface, most
tasks take place multiple times, or take an extended period of time to perform.
Design features can support users in completing tasks accurately and
quickly by off loading much of the need to remember things, which can be
achieved by using computer storage.
Additionally, tasks usual require information to work on, and create information
as a result.
Certain forms of that information are more efficient and effective than
others. We’ll look at
considerations that you might want to build into your requirements regarding
At this point we can start designing algorithms that will
assist us in transforming our data inputs into our desired outputs.
We’ll talk about ways to derive these requirements from the earlier task
scenarios we defined in conceptual design and worked out during cognitive
Release and Production
At this stage, we should be pretty sure we know what we
want to build. We have very
complete requirements of what the hypothesized product or service should be, and
pretty good expectations about how well we expect it to perform when we give it
to actual stakeholders.
Prototype Usability Tests and Product
So, now it is time to actually build parts of the product
and test our hypotheses, and refine our design if we aren’t seeing the results
we expected. We talk about how to
use the tasks scenarios we talked about earlier to verify that we are achieving
our design goals. This allows us to
reduce even more risk before committing to final code. This section talks about how to perform actual usability and
verification acceptance tests.
Release, Ship and post release field
Now we have a finished product or service and we start
delivering it to our stakeholders.
Are we getting the results we expected? Why or why not? We learn how to verify our successes and build on them, and
how to recognize our mistakes and fix them.
The SWIFT team
This section describes the composition of the
interdisciplinary SWIFT team that performs the SWIFT process.
This section also discusses important behavioral rules guiding how joint
design is performed.
This section contains information that you may want to
use as reference material, such as pointers to other books that may help you
develop your SWIFT skill further, and Examples of deliverables that might be
produced in various steps of the SWIFT process.
Here are some references to books and other materials and
individuals that have influence my development of SWIFT design practices.
By going to these sources as well, you can deepen your intuitions
regarding SWIFT as well.
Some examples of deliverables from various stages are
included here to give you an idea of what these documents might look like.
About the Course Author
My background is as a software designer and executive
with more than 25 years experience designing, developing and managing software
organizations, in R&D, Engineering, Product Marketing and General management
positions. I’ve worked at several
of the largest computer companies, including ten years at HP, and a stint at
Sybase, but I’ve also worked and consulted for many start-ups which is where a
lot of new product design takes place.
While I’ve been General Manager, VP of Engineering,
Director of Software Engineering, Product Marketing Manager, and many other
titles, my favorite title (which I got to pick for myself) is EXPERIENCE
DESIGNER. As you work through the
SWIFT process you’ll see why this is an apt title for the skills this class will
train you in.
At some companies, the locus of product design is
Engineering. In others it is
product marketing. Some places put
it in program management. Wherever this responsibility is located, and whatever
you are called, if you are determining the requirements and design of new
products, you are doing “Experience Design”.
I am hoping this class will help you be more successful in this role.
I’ve occasionally taught my SWIFT method in classes
offered through University of California at Berkeley, and University of
California at Santa Cruz, particularly through the extension programs that are
aimed at continuing education for current professionals.
I’ve also lectured on this topic many times for the Association of
Software Design and also for the World Wide Institute of Software Architects at
locations such as Stanford University and Xerox Palo Alto Research Center.
This method is the heart of my consulting practice,
offered through Prescient Software. This consulting is typically offered to
senior executives and supports development of business plans, and product plans
as well as supporting many fund raising and customer awareness activities, as
well as supporting actual implementation of final products.
Although this method was originally developed to aid in the development
of software products (my personal area of expertise), I’ve found from the people
that I have trained that these methods are applicable to new product designs of
all kinds of products, from VCRs and calculators to laboratory instruments and
The origins of SWIFT
Designing the Products and Services that Customers want, through Experience
I developed the SWIFT process over a period of years from
my experience designing and developing products at several companies, but
particularly at Hewlett-Packard between 1980 and 1990.
During that time I developed several technically interesting products,
which were not commercial successes. While it was great to be the subject of an
editorial in a major computer magazine (Unix World) because of these technical
successes, and to be invited to speak at many conferences, this was ultimately
unfulfilling, because we weren’t able to commercialize our products.
As I became more aware of the reasons our work couldn’t
be commercialized by HP, I resolved to avoid this situation in the future by
ensuring that a commercial market would be available for my products before
building them. At the same time, I
had seen far too many product designs that sales departments were eagerly
building but which engineering could not build.
I didn’t want to make that mistake either. So I set out to figure out how to build products that
could sell, and sell products that could be built.
SWIFT came out of this, and my first success with it came
shortly there after when I lead the design of MergeAhead, a simple product that
allows two people to simultaneously edit the same document (e.g. one programmer
fixing bugs and another developing new features) and then use MergeAhead to
combine them into a single document with everyone’s changes.
This product received a cover notice in Sun World at introduction,
because of its simple and elegant design – a rarity in most version 1 Unix
products at that time. Seeing the
many users benefiting from frequent use of MergeAhead and its successor
MergeRight has been very rewarding.
If I go to the trouble of building a product, I want to know that the efforts of
my colleagues and myself will not be in vain. Seeing customer testimonials is
the highest personal reward.
What does SWIFT mean?
SWIFT is actually an acronym for SoftWare
This captures part of the initial insight and impetus to SWIFT.
The Software part is obvious, I was developing Software products
and so that was what I was designing a process for (though it turns out to be
applicable to many other areas).
Imagineering is a word coined by Walt Disney to
capture the essence of an imaginative understanding of the needs coupled with
artful engineering of solutions.
Fellowship Teams is a name I used to distinguish a
particular kind of cross-disciplinary team.
I’ve found that the best way to ensure success is to ensure that all the
bases are covered, and that every discipline has some bases it covers better
than others, others that it does less well.
By building inter-disciplinary teams we can have the ability to get the
strength from multiple disciplines and participants. For instance, when I developed MergeAhead, I had a technical
writer and a trainer involved in the design – but their goals were different
than usual, this time it was to help ensure that no manual was necessary
(because no one would want to have to read one) and that no classroom training
was necessary (because if the product required it, people wouldn’t adopt it
Fellowship teams differ from other interdisciplinary
teams in one particular way. In
many teams there is a pecking order: Senior Manager, Engineers, Marketing,
Technical Writers and Trainer, Support staff.
But this pecking order gets in the way of good results when there is a
question that is really the domain of expertise of someone low on the pecking
order (like Technical Writers or Support staff).
Often time their very valuable contributions are ignored.
So to avoid that, in Fellowship teams we have a rule.
Every member must have at least one area where they are regarded as the
final expert, or resident “Fellow”.
They are required to LISTEN to input from any other member in any other area.
But in any design decision concerning the fellow’s specific area of
authority, they will have the final decision.
I find that this not only builds better respect and working relationships
among the team members but it avoids some of the real problems that can occur
when design is performed by consensus in a committee (Remember the old joke that
a Camel is a horse designed by a committee?)