productofwhat

Like many engineers, I was introduced to requirements in a fairly informal way.  There was no fan fair about it, I was just told “here are the requirements, now go design a product”.  Most of the time, these requirements are fairly detailed.  Sometimes they are so detailed that you actually don’t design anything, you just implement the requirement.  And like most engineers, you look at those requirements and ask “why are these important?”.  Or worse, you hear that same question from the customer!

You can smell a bad requirement pretty quickly.  They usually feel constrained, but vague.  If there is a rationale associated with it, they tend to have a lot of words, but basically boil down to “because I said so”. More importantly, the tell tale sign is when you find no one actually talks about them, or when they do its so deliberate that you wonder if they believe it.

So how do requirements get to that point?  Part of the problem is a disconnect from the customer.  Either there isn’t one, or there are so many of so many backgrounds that the requirements become generalized.  The other reason is that the person(s) defining the product requirements already have an idea of what the product should look like, usually well before they understand what the customer wants (which is the first problem).  So what happens are requirements that describe the final product.  Sometimes that’s ok, but a sports car and a bicycle can both satisfy a person getting from point A to B, but one will cost a LOT more in development.

There is a huge risk in either case.  Besides the potential issue of not meeting the needs of your customers, the risk in defining the product early on means that the engineers are working towards that goal.  In the sports car example, engineering will focus their effort on designing a sports car.  They will research aerodynamics, optimize the drivetrain, and investigate high tech materials.  If they knew the customer just wanted to get from point A to B, they may have just designed a bike

So how do companies break out of this?  First, the product manager needs to truly understand what a customer wants.  Ignore what preconceived ideas a product should be and just listen to the customers concerns.  What is keeping them from achieving their goals?  Sometimes the customer will design the product, but that’s another topic.  Its an abstract exercise, but in doing that you get more intimate with the customers needs, and you open the door for more creative conversations with engineering.  You get a team that wants to contribute in solving the problem, not a team that “is doing what it’s told”.

As an engineer, its your job to question.  If something doesn’t feel right, ask.  If the PM can’t clarify, understand why.  Don’t be an engineering zombie doing what its told.
The riskiest thing you can do is accept a requirement without understanding the importance of it.  At best, you create a product that might not quite hit the intention of the requirement, at worst you make a product that isn’t what the customer wants.  And who doesn’t want to make great products for customers?

Being an engineer, I’m tempted to thinks through things as an engineer.  Over the years, I’ve been trying to be as objective as possible when trying to solve a problem.  I write requirements in a way that facilitates discussion of the solution, not giving any preference to one design vs another.  So, when I talk to an IDer, It can sometimes clash with my world.

To be fair, most of the products I’ve developed have been engineer biased.  Lab instruments for example, don’t often need to be too aesthetically pleasing to sell (some customers are just happy to finally have the capability).

The other day I stumbled on this, and I have to admit I’m kind of excited about it.   First thing I noticed is the complete lack of engineering.  In fact, it looks entirely plausible to release a product without ANY engineering.  Really? No engineering?  And that is when I start to get a little bit concerned.  Not because people are making products without good engineering, but rather the workflow they describe is simplified.  There are a lot of influences in the development of the product.  Someone helps articulate the customer needs to ID (“does a customer want a handle, or do they want the ability to carry?”). And hopefully someone sits down to look at the proposed design before they make a prototype (“can this product be reasonably carried? is it too heavy? too cumbersome?).  There are so many inputs and outputs to the workflow, its easy to develop a product that just doesn’t hit the mark.

I imagine that’s not the intention of the article.  Of course ID takes into account customer needs.  And someone ends up “crunching the numbers”.  But I would love to see this workflow merged with a great product development workflow to see how all the pieces connect.

All that being said, I think IDers have it hard.  With engineering, you can claim domain knowledge, and others will listen (most of the time).  With ID, everyone can be a critic, and there is never a shortage of advice.