Summary
Read most any software engineering text book and
you'll be told that requirements gathering
is key to successful projects. Yet, many projects in
start-up companies never develop such a document or,
perhaps worse, have useless, sketchy documents that
serve only political needs. What's going on here?
Advertisement
"The best way to perpetuate a bad system is to work around it."
-- Anonymous.
The Search for Requirements
Read most any software engineering text book and
you'll be told that requirements gathering and an
accurate software requirements specification (SRS)
is key to successful projects. Yet, many projects in
start-up companies never develop such a document or,
perhaps worse, have useless, sketchy documents that
serve only political needs. What's going on here?
In this weblog, I'll relate some of my experiences
with requirements gathering in small companies and
start-ups. I'll also explain why I believe this is
one aspect of the software crisis that shouldn't be
blamed on developers.
That Vision Thing
Who owns the vision for the product? In the early
days of most start-ups the answer is clear: the
engineers who started the company. Soon thereafter,
however, it becomes less clear. The accepted thinking
is that engineers, while adept at building things,
aren't in touch with customer's needs to
create solutions usable by normal people.
Further, it isn't just Human-Computer Interface (HCI)
concerns that worry management.
Product road maps should account for sales cycles,
competitive analysis, marketing initiatives, market
trends, and other factors outside of engineering
considerations. So, there are plenty of reasons
why the nerds shouldn't unilaterally declare what
product is built. That should fall to the
product management function, a person or
persons responsible for specifying the product's
features and appearance, burdened with making
the hard choices, and charged with having the
vision for the product and instilling that
vision into others.
In the small companies I've worked for, this is a fairy tale.
When I hear the words "effective product management" I think
"Unicorn". I've heard lots of things about both; I've seen neither.
Let's forget for a moment most of the things I've listed above.
Forget about the market analysis, the bold leadership, and the
ability to make difficult choices. Let's concentrate on the
vision thing and the ability to instill that vision
into others. An SRS would be an ideal vehicle for this. Yet,
I've never seen a product manager produce such a document.
Nor have I seen anywhere close to the amount of detail such
a document would need in any of the meager writings a
product manager has produced.
The Devil is in the Details
I believe the problem here can be neatly summed up in with
just a couple of points:
Most people don't write well.
Communicating in writing is not easy and most
people don't do it well. It can be grueling, time consuming,
and unglamorous.
Writing requires courage most don't have.
Even if you can write well, it takes a certain amount of courage
to make a tough decision and the put it to paper with your name
on it. In a politically charged organization (and which ones are
not?), such a document can hang like the proverbial albatross
around the author's neck. It is much safer to "not go on the record."
Product managers are not usually schooled in software.
Say that you've found somebody courageous and articulate, chances
are good that they are not schooled in software engineering, HCI,
or other related fields. An effective SRS should be clear, unambiguous,
and useful for its intended audience: the software development team.
All writing speaks to an audience. If you don't know your audience, you'll
likely fall short in your writing.
I've struggled within companies where a product management function was
mandated by top management and the results were, without exception, either
embarrassing, disastrous, or both. Here are a couple of stories to illustrate
my point.
Story #1
I worked for a company in the early 1990's that made systems that went
into restaurants and resorts. When I first arrived, engineering was creating
a new product to replace the aging, existing product. The head of software
development tried to solicit requirements (or at least ideas for the product's
features and its interface) from the part of the organization responsible
for product management, but failed on each attempt. It was especially important,
argued the software development manager, to get input and advice regarding
the HCI aspects of the system. It wasn't at all obvious how a restaurant
manager, for example, would wish to view the configurations of their terminals,
or enter data about their staff.
As time passed, the development team created
their own interface so testing could proceed.
In the end, it was that interface, the one created by the
engineers for their own testing, that shipped with the product.
It was not loved.
Product management was quick to claim that
engineering hadn't listened to them. Of course, there wasn't a single
sheet of paper, not one document, not one memo, indicating product management's
wishes or demands. Nevertheless, upper management sided with product management
on the issue and chastised the cowboys in engineering for running off and
creating something without due guidance. The nasty cold war didn't last long,
though, as bankruptcy soon obliterated upper management, product management,
and nearly all of engineering.
I was one of the three nerds left in engineering in the new, reconstituted
company that emerged from the bankrupt original. It wasn't long before the
development manager quit and I was promoted to lead engineering. In the next few months
I rebuilt the team and we fixed as many bugs as we could, as quickly as
we could.
The new management team, brought in to turn around the company, again
demanded that a product management function be established. The new
product manager, a nice enough fellow, seemed unwilling or unable to
put any thoughts on paper. I had many ideas that I wanted to explore
to move the product forward, but each time I'd broach the topic, the
company President would insist that such things were the product
manager's role and not mine.
I encouraged the product manager, I cajoled, and I pleaded, and offered
to write if he would only read and approve. I would do all the work, if
he liked, and he could take all the credit. Yet, we were still at a stalemate.
I understood his reticence. The new senior management team was ruthless
and unforgiving of mistakes. Writing something that wasn't received
well by these cutthroats might well lead to his dismissal.
He wanted to keep his job; I was at a point where I no longer cared.
Finally, the Board of Directors (representing the new investors)
wished to see our product plan. I wrote a 25 page "vision" document
that was passed up as our long term product plan. To my knowledge,
no mention was ever made that it originated from the me, the VP
of Engineering, and not the product manager. Yet, that vision stuck,
which is all I cared about. I left not long afterwards.
Engineering was forced to run the entire project, from the moments after
conception, up until the day I left, with guerrilla tactics. A product
was made that eventually became good enough to fuel the resurrection
of the company after bankruptcy, but the cost was high.
It was impossible to get buy-in from a product management function
or upper management before, or even during, development. There were
no leaders, only art critics, happy to
distance themselves from any controversy, and yet thankful that a
product existed to enable sales and their own paychecks.
Story #2
A friend related a story where the engineers wrote the requirements
so "the product manager would know what we were doing". Help me
understand what value the product manager had if he (a) didn't
lead, (b) simply watched the engineers do his job, (c) and required
the engineers to spoon feed him the plan (in the unlikely event that
somebody might ask him about it, I suppose).
Story #3
I think I saw a glimpse of this problem from the outside at
the recent JavaONE conference in San Francisco. Scott McNealy,
President and CEO of Sun Microsystems was the keynote speaker on Friday,
June 13th and he brought up several guests including
Verizon's chief information officer
Shaygan Kheradpir. Kheradpir demonstrated Verizon's Digital
Companion, a product that provides
dynamic rerouting to and from various
numbers, interception of urgent calls, and so on.
You can read more about it
here.
At the end of the crowd pleasing demo, McNealy asked
Kheradpir why this project had originated in engineering
instead of marketing (or product management). The first
answer provided by Kheradpir was a joke, "well, we're smarter than
they are", but he quickly followed with the stock, politically
correct answer, "we listen to our customers, blah, blah, blah."
How did McNealy know that the project was done "skunk works style"
and not through regular product management channels? More
importantly, why was it that nobody appeared surprised by the revelation?
Could it be that even big companies have this product management vacuum?
Perpetuating a Bad System
This is not a software problem. Read that bit again. This is not a software problem.
The problem, simply stated, is this:
The requirements gathering phase, one of the most important phases of a project,
according to the literature, is heavily dependent upon untrained people who are only
marginally interested in doing the work. Further, upper management is likely
to insist that those who might be trained stay out of the process.
Since so few examples of good requirements documents exist, it is easy for
these untrained, unmotivated, product managers to pass off sparse, terse,
useless documents as an SRS. Upper management is unlikely to assess or understand
the SRS's importance or quality, if, indeed, such a document is ever produced.
The best way to perpetuate a bad system is to work around it. This
is a bad system and software departments are forced to work around
it. When we do, we win: we ship product. Guerrilla tactics of working
around, or behind, or in spite of, an inept product management
function can still lead to a successful product. But at what cost?
Engineers are fond of their ability to drive to root cause for a
given problem. When it is a technical problem, we're very good at
quickly isolating the root cause. This problem, with the myth of
product management, isn't a technical
problem; it is a social problem. Oddly enough, engineers aren't very
good at dealing with social problems. So, what do we do?
I don't think the role of "product manager" is going away.
Our only chance is to try to encourage the right kinds of people,
folks who have a keen sense of the appropriate technology,
good communication skills, and an attention for detail, to fill
those positions. We also need to get business schools and management
degree programs to recognize that this is part of their world, too.
If management is going to fill these positions with MBAs, then
we need to make sure that these people get the education they need
to do the job correctly.
This might be a book opportunity as well. Instead of writing
every software requirements book as though an EE is going to
read it, perhaps there should be a few assuming a well meaning,
hard working MBA is going to read it.
I do believe that continuing down the road we're on now, continuing
to work around the bad system we have, will only make things worse.
Applications and environments are getting too complex to have
these kinds of distractions. Guerrilla tactics or no, there
will be a breaking point when even clever development managers
can no longer circumvent the system.
What Do You Think?
This is a bit more lengthy than I expected but it is an important
topic. I'm interested in your views. You can write me directly or
post your comments here on Artima.com.
Resources
Software Verification and Validation for Practitioners and Managers, Second Edition,
by Steven R. Rakitin. See the description and my review on
amazon.com.
Lockheed Martin's Skunk Works, by Jay Mille. Read the description on
amazon.com.
I found story #1 scary in that it was eerily familiar.
One thing I've taken to doing is designing the most horrible interface on products as I can. I'm not very good at designing interfaces to begin with, so this isn't hard for me. This does two things.
1 - It forces somebody that cares and has the talent to design an actual interface that real people will use
2 - It proves to me that I've done a good job on the back end design. If rewiring the app to a new interface isn't hard, I figure I must have pretty good seperation of presentation and implementation. If it IS hard, then at least I have a chance to refactor it before it goes out the door.
I've worked with good, bad and mediocre product managers. The toughest ones for me are the mediocre ones. Good I really appreciate and bad at least I know what to expect. Mediocre you get to wait and see every single time because you don't know what's going to come out of the next set of requirements, assuming that they come at all.
I still wonder just what it is that stops most in Product Management from actually sitting down and getting pen to paper (or more accurately, starting up MS Word and getting their fingers moving on the keyboard) and actually writing something that can be called an SRS.
I have experienced the same frustration previously, where a team of 3 product managers spent months and months doing who knows what and could not produce a single document. They forked out a ton of money and brought in a contract developer to install the DOORS software product which was never used. They brought in consultants (more money again) and had numerous meetings to again produce nothing but a bunch of Gantt charts. Arrgh! If only Gantt charts were actually useful for developing software products! Does anyone else hate them as much as me?
All the while, the development team just wanted something that we could take as the requirements so that we could try and get out of the rut we were in. Development Team has vague verbal requirements - QA team has no idea what they are testing - Customer doesn't get what they want and tells management what needs changing - Dev team gets a 2nd hand verbal version of required changes and so on.
First I thought that perhaps Product Managers were all too busy to write an SRS. They did have a lot of meetings and they were always trying to understand how to use DOORs. Even so, surely they can't be too busy to do the single most important part of their job!
Then I thought that perhaps they were incompetent. This is possible. As you say, writing is not easy. Using DOORs is not easy either, nor is using MS Project to produce Gantt charts, but they worked both of them out. They were actually intelligent people.
I came to the conclusion (and until reading your article thought that I was they only one who thought this) that it is actually fear that stops most in Product Management from actually writing an SRS. I don't really understand what the fear is. I guess the fear is that a document lying around with their name on it could easily be used to blame them when the next thing goes wrong.
This fear is probably well founded. I can believe that there are CEOs (or others in upper management) who could hire product managers and be very happy with those that produce nothing, and chastise those that actually do something and have an SRS to show for it. I can believe it because I've seen it.
If the problem then lies with those at the top of the company, well there is probably little that developers can do about this whole problem. I agree with you Scott that books and training that are aimed at management rather than engineers would be very useful. I would also add:
For developers: Encourage anyone who actually writes an SRS. Be constructive (rather than critical) with your feedback.
For Product Managers: Writing an SRS is not easy, but its not too hard either. Joel Spolsky http://www.joelonsoftware.com has some great articles 'Painless Functional Specifications' on how to write software requirements. Be courageous and just write something. If you are too scared to commit to anything, then just label all your documents as 'Draft' - but just write something.
I found myself becoming angry as I read this. The examples hit too close to home, I guess. The (nearly universal, from my experience) inability for product managers to take responsibility for defining functionality unambiguously and authoritatively (e.g. written in either email or paper) really gets to me.
Having the Product Manager not schooled in software or the area of programming required for the project usually spells disaster if they are left up to the project requirements gathering
I got tired of the general fuck it up view of the corporate world and thus I am now running my own comnpany/development shop..
Do not ge tme wrong there is large diffence between doing something 100% r and d in which it has to be skunworks style and soemthign in which 80% is known becuas eit has been encountered before by the Proejct mangament staff..
A clear example of thsi is new features added to an existing product or framewrok..
But I think coproratiosn get lulled into false security and think becasue ti worked in this case it will work with defining a new product adn entering a new market at the same time..
Wow, story #1 rings horribly true for me in a number of ways.
I think it's interesting that you draw out vision as being so important.
My current thoughts on vision vs requirements go as follows:
(1) Customers don't have vision - they have a list of things they think your software should do for them. They care little for whether these requirements fit with your vision or fit neatly with your product. They just need it and now.
(2) Product Managers don't have vision and yet are expected to have it.
(3) Engineers have vision but, because it's vision, it might not appear to satisfy an immediate customer need. This is different from the customer not wanting it - they simply haven't stopped to think "what if" at that level of abstraction.
(4) Vision generates requirements as do customers and balancing between the two (and having the guts to say no to a customer requirement that doesn't fit with your product direction) is hard.
This is really a great essay! Just a couple of comments:
First, it may be that many software companies employ more people than they probably should. Sometimes having fewer people, but empowering those fewer people more, is more effective than having more people, but with all the divisions and politicking you write about.
The reason that that is often not happening may have to do with how software companies are often structured. The main culprit , paradoxically, is investment capital. Investors often want to excercise control over a company by putting in charge folks that they (the investors) are comfortable talking to, i.e., folks who can talk the business lingo, and are good with spreadsheets, etc., but who have little or no knowledge about software development, product development, and who may not even be all that passionate about the company's line of business and customers. So these folks then put in place a middle line of managers, i.e., product managers, project managers, etc., who supposedly can "translate" between the business and technical sides. So the developers are totally disempowered from running the businesses - something that you describe so well in the essay.
On a more important note, I really no longer believe in the concept of a "product" at all. Why product management often doesn't work out may have to do with the fact that product managers are trying to define something that is less and less relevant. I tried once to develop a "product," only to come close to losing all my savings, and stopped the effort only when I came close to becoming homeless.
Instead, what I realize is that my customers never really ask me about a product. They express their frustrations, or their hopes, or how they could improve their business if they could do X and Y, etc., And helping them do that X and Y typically boils down to making available on their network, or PC, or whatever they use for those tasks, a handful of software-based services that support those tasks. Now, I have to call a given set of those services a "product" only because that's what I write on the bill of sale, or license agreement, and that's how they pay (or, that's one way they pay, and that's not even the most effective way to get paid). But "product development" in that context often means tying these very simple services together in likewise simple ways. If you have an infrastructure that lets you easily tie simple services together - e.g., Jini - then "product development" is often an issue of configuration, more than anything else.
Regardless of how software is built, developers must communicate with customers regularly. That communication cannot be circumvented by a layer of management. The reason is that customers will tell you what works for them and what doesn't, and how they'd like to improve their business with etc., Customers can also be aggrevated when talking to middle management, instead of talking directly to the folks that know the product in and out. Imagine going to a doctors office, only to be interviewed about your ailments by a doctor's manager, or a "treatment manager," who would supposedly translate your layman description of the problem into doctorese. That's just nonsense.
As a developer, when you talk to the customers regularly, you can then decide what ingredients (services) you already have, and what's needed to enable new functionality. Then you can quickly implement what's needed, deploy it right away, and get immediate feedback directly from the customer. Instead of developing many features at once, and then deploy everying as an "upgrade," it's often more effective to deploy new product features one at a time, and get feedback right away. That process then becomes the product development cycle. Of course, needless to say, you're not going to implement everything every customer wants, only the services, or features, that you think you can make money from. But here, too, let the market place decide what's a good product feature, instead of some produce development manager. If you put 1 month into developing something new, and nobody seems to want it, then 1 month of effort is the most you've lost. It think it's preposterous to think that a single person (the product manager) can be smarter than the market as a whole.
Excellent! Your clear-headed truth-telling will make you popular with software engineers, and your name will be mud in managerial circles. This latter fact will save you huge amounts of time.
One further point: isn't it strange how the same product managers who refuse to even provide a specification for the functionality they want apparently have no trouble splitting the project into phases and assigning times to the steps of each phase in Microsoft Project [though I presume at Sun you will use some politically correct equivalent]?
It's like a variation on the art critic: "I may not know what I want, but I know how much budget its manufacture will require". Coincidentally, of course, this is usually the amount they think can be extracted from upper management.
Starting with requirements rather than a budget is so unusual, though, that such an approach can hardly fail to be seen as heretical.
In an organization where responsibility and credit for any part of the development and marketing of the product rests with people who do not understand the technicalities of the product, or who do not know or care about meeting the end users' needs, the software development process is subject to political interference and management stupidity and is very likely to be dysfunctional. I have been there and done that.
That is why really good software usually comes from a small company of intelligent and dedicated people, or from a small, somewhat autonomous group within a larger company. There is no substitute for having excellent, caring people at all levels.
Huge or extremely complex software products, that cannot be done this way, will often turn out to be expensive flops - as written up by Mr. Brooks - or products we all love to hate that come from large companies we love to hate, developed by people who see themselves in the Dilbert comic strip every morning.
This thread has raised some very insightful comments.
I would argue with some of the comments made that have pointed fingers at Product Management for not having anything in writing. I believe this is somewhat true (my experiences have shown this), BUT the problem usually isn't so easy to pin point, its actaully company wide. Especially with regards to startups.
Most failures happen because the actual value propositions just aren't strong enough. Viable businesses can't just survive on a cool technology nor can they survive on vapourware. There's a specific balance that has to be met, one that captures a unique technology idea, markets it to the correct stakeholder(s) with the right level of engagement and message, this is what yields progress! Winning is something that just simply comes with time.
But reality shows that creating unique value propositions is hard, so most VC funding is based on management team credentials, vision and buzz words (this is changing :-). The challenge is how adaptive a company can be once they're funded. Engineering will always have to work in uncertainty, making sensible assumptions is the only way. Product Management have to understand the market and help Engineering focus they're development efforts. The key is that both units have to work together! Simply writing a set of requirements that reflect a winning product to Engineering just isn't reality. Its about a collective effort with clearly defined role/responsibilities. Testing the success of each product release with the market, refining and tunning the product. Release early and release often is very important in the early days....
There is no one answer, and this is what makes startups so majical. Its about people that work together, at some level, you need clear roles but these will always be blurred. Its about a common vision, skilled professionals and a big lottery ticket and nothing more.
Hello Mr. Anderson and all the onlookers perusing his blog...
I enjoyed this posting and had a question that (hopefully) you, or someone, can provide guidance on.
I am a Marketing Manager with both a keen grasp of the English language (and the ability to parlay this talent in writing) as well as a personal interest in (and moderate insight on) the world of information technology.
Despite what many would consider a rare find, my knowledge of "technical stuff" has often times caused dissention between myself and the 'career-techs', as nobody particularly likes to be challenged by someone in a different department, especially a creative department, and who actually might know a thing or two.
But, keeping things "on point":
We (collectively, the entire management team at my company, including Marketing, IT, Sales and Executive Staff) have finally come to an agreement on the need for better reporting. As a result, we are in the beginning stages of developing our needs (both individually by department, and collectively as a company), and have been advised (from IT) that we will need a formal SRS developed, to ensure that we are:
1. meeting the needs of everyone on the project team and 2. specifically detailing how we plan on achieving that end
Somehow, I have been asked to hold the pen.
Now, with that said, I have no problem with taking the lead on this as I truly enjoy writing, reporting, and being a part of the development team for any project, however, I am not ashamed to say that I do not believe I am the expert in this area, nor do I have the experience in writing such a document, (which will inevitably contain the direction, and the owning of said direction, to either purchase a software solution, and/or incur the expense of outsourcing the majority of building the new UI to a third party programmer).
When I mentioned this to the IT Manager who was busy "coaching" me on how to write an SRS, providing a 40+ page example of one he recently completed for me to use as a reference, he said that the SRS is either written by the IT department or the Business Owner. He of course was relating our scenario to the latter solution. But I am very skeptical of his motives. Is he possibly pawning this labor-intensive, time-consuming project onto the petite Marketing Manager who thinks she's such a know-it-all so she'll be happy to take this off his plate, or is it possibly even more sadistic, in that he is putting the ownership of the outline, direction and documentation of this project onto someone who is obviosuly not the expert here, so that if/when Executive wants to know why something went wrong, cost so much, required x purchase, etc., the finger can be pointed away from him and into my direction?
I'm not typically a paranoid professional, but I recently was met with an irate email written by the company President who was told that Marketing directed IT to delete certain records from our CRM, and as a result, his personal account was wiped out. What he WASN'T told was that IT recommended that we delete said records to avoid them skewing our reports in the future, that I spent 4 hours of Marketing time going line by line through an innacurate report that IT provided in an effort to assess where the reporting error was, and in turn, identified x records that "appeared" to be dummy/test records, and that we should delete them from the CRM. (I don't know about you, but if I was the IT Manager and owner of my department, should anyone from a different department request that I "delete" records from our corporate database, you better believe I would ensure that each and every record was, in fact, dummy/test before doing so - simply because I am the owner of my department and at the end of the day, the only one responsible for my actions.....) Apparantly, our IT team didn't take the same pride in their department, and simply deleted said records without doing any QA/QC on what they were about to remove. Needless to say, I was thrown under the bus.
(exhale) OK - Im back - and I am SO not bitter!!!
So, net-net, I was wondering if this responsbility (writing the SRS) should realistically be in the hands of the Marketing Manager, even if she may be the best "writer" (so-to-speak), and even though she may be 1 of the only 4 people in the company who may actually understand what it is we need to do for this project? I would think that my involvement in the business requirements such would be essential, but the actual compilation (ascertaining each department's specific needs to get the full project scope) and the writing of the document should be completed by the owner of IT, no?
So sorry for the lengthy post, but needless to say I can't sleep right now and could really use some advice...
> I enjoyed this posting and had a question that (hopefully) you, or someone, can provide guidance on.
> So sorry for the lengthy post, but needless to say I can't sleep right now and could really use some advice...
Two pieces of advice: 1) Don't post an unrelated question onto the end of a seven year old discussion thread. 2) Don't post long random rambling thoughts with no clear question at the end?
Wow Vincent - thanks for your expert opinion. So glad this is a community of well-versed, helpful specialists willing to help a fellow colleague out.
Two pieces of advice:
1. Don't advise not to respond to a seven year post if you obviously were still reading the thread seven years later. 2. Keep your miserable, unfounded and downright pessimistic opinions to yourself. Nobody likes an asshole.
Previous Topic
