Just Say No to Features

Yaacov Apelbaum-Just Say No

A quick feature inventory of most “mature” commercial software products like Microsoft Word, Lotus Notes, etc. reveals that more than half of their features are either never accessed or are outright useless (the historical evolution of the Microsoft Word tool ribbon is an example of feature bloat). If you are developing software in a startup, useless features will be the death of you and your product. The secret to developing the right set of features is learning how to say no to the rest.

Yaacov Apelbaum - Word 1.0 ribbon

Yaacov Apelbaum - Word 6.0 ribbon

Yaacov Apelbaum- Word 2003 ribbon

Yaacov Apelbaum - Word 2003 ribbon

Yaacov Apelbaum - Word 2013 ribbon
Figure 1. Bloat progression in Microsoft Word from version 1.0 to 2013

Whenever you say “yes” to a new feature, you agree to adopt a baby. And with the baby come such responsibilities as changing it’s diaper, waking up at 3 AM to feed it, and paying for its education (e.g. architecting, developing, integrating, and testing).

To hit the market early and within budget, your feature development strategy must focus on creating the bare essential functionality. So in this vein, stay away from developing a Swiss arm knife with dozens of capabilities solutions.  You should make each feature prove itself to be a “worthy survivor”. Your features need to be tough, lean, and mean. Embrace the SEAL’s “hell week” screening approach before letting any one of them into your development cycle.

Yaacov Apelbaum - Swiss Army Knife Bloat

Whenever product, sales, marketing, or even the CEO requests a feature–it should instinctively meet a resounding no. If you don’t feel comfortable saying no, try a variation along the lines of “not now honey, I have a splitting headache” or “I’d love to chat about this feature, but I’ve got to run into a day long meeting right now”. If you are cornered and can’t escape, listen and take some notes, but stop there. There is no need to be heroic or do anything just yet.

If a request for a particular feature keeps surfacing over and over again from different sources, that’s when you know it’s time to take a closer look at it. Only at this point should you start considering it seriously.

What do you say to the product team that complains vocally that you won’t adopt the top one hundred features on their wish list? Remind them that developing even the most basic feature is prohibitively expensive. Alternatively, you can use the following list of tasks to illustrate the amount of work needed to insert a simple image on a MVC CMS driven web page:

To develop this feature, you need to (times are in minutes)…

  • Hold a management meeting to discuss it (30 min.)
  • Hold a feasibility meeting with the technical teams (30 min.)
  • Develop a schedule and if you use SCRUM work the feature into a sprint (30 min.)
  • Develop screen wireframes (60 min.)
  • Develop HTML mockups (60 min.)
  • Develop a POC (120 min)
  • Allocate resources that are working on other features (30 min.)
  • Develop an analysis and design document for system impact, (30 min.)
  • Create a code branch (30 min.)
  • Write unit tests (120 min.)
  • Write the code (120 min.)
  • Peer review the code (30 min)
  • Merge the code back into trunk (30 min.)
  • Test, revise, test, revise…(60 min.)
  • Modify user documentation (30 min.)
  • Update the product guide (30 min.)
  • Update the marketing and engineering collateral (60 min.)
  • Refactor product cost and check to see if pricing structure is affected (60 min.)
  • Deploy to production (30 min.)
  • Cross you fingers and hope that everything worked out as planed
  • Total development cost = two days of work

As you can see from these steps, even the most basic feature request can cost two days of planning, design, development, testing, and documentation effort. On average, feature tend to be 5 to 10 times more complex.

Sometime User Feature Request Can be Evil 
What about using your customers as the main driver for feature development? Well, this strategy has several small flaws as well. Your customers want everything under the sun, yesterday, and for free. You shouldn’t fault users for making feature requests. I encourage our customers to speak up and I diligently collect their input. In the end, most of our functionality comes from user requests.  But as I have indicated, even for user feature requests, my first response is to always say no. So what do I do with all these new customer feature requests? I read them, try to forget them and finally, for safe measure, I putn them in a backlog file.

It sounds terrible, I know, but don’t worry, if the feature request is important enough, it will keep on coming back and you won’t have any difficulty remembering it then. These persistent features will be the ones essential to your products that you will need to prioritize and implement.

It may not be apparent, but most software feature surveys revolve around questions like “What features are missing in our product?” or “What what would be the one feature you couldn’t live without?” or “What would make this product a killer app?”. Rather than continue to ask for more in this way, the questions that you should be asking are “If you could remove one feature, what would it be?” or “How would you simplify the product?”. Sometimes the best thing you can do for you product is to develop less.

Now go ahead and practice your newly acquired skill of just saying no.

© Copyright 2011 Yaacov Apelbaum All Rights Reserved.

Designed for Humans

Yaacov Apelbaum-Designed for Humans

In my previous life, I was a civil engineer. I worked for a large power marine construction company doing structural design and field engineering. The work assignments were pretty interesting. I got to blow up a bridge, salvage a sunken vessels, and build a lot of interesting marine structures.  On one of my projects, I was given the responsibility to design a set of beds for pre-stressed concrete piles.  The design challenges in this project were significant. We had limited real-estate and the loads involved were higher than any previously attempted.

Yaacov Apelbaum-Prestressed Concrete Piles Beds for pre-stressed concrete have massive anchors on each end. Between them steel forms are placed and steel cables are strung.  The cables are first tensioned, then the concrete is poured into the form.  When the concrete hardens, you cap the cables and cut them.  The result is a pile or a girder that is significantly resistant to various loads.

Following best engineering practices, I completed a structural load analysis document, a set of production blueprints with full dimensional drawings, welding, coating and assembly instructions, a bill of materials, and even a balsa scale model to help the manufacturing facility to visualize my design. Yaacov Apelbaum-Prestress Bed Scale Model

I was proud of my hard work and I felt that it was a great achievement.  The day before the presentation, I went over all the calculations again and rehearsed my slides.  After one last sleepless night, I arrived to the conference room to find several structural engineers, the yard superintendent, a number of field engineers from several divisions, and the chief engineer from corporate, an elderly white haired gentleman in his mid-sixties.  I remember feeling confident in my ability to sell my design to them.

The entire presentation went off without a glitch.  There were some stylistic comments but the overall feedback was good.  After the presentation, the chief engineer stopped by, shook my hand, and said that he liked my design very much.  Then with a straight face, he told me that he expected to see two additional alternative designs before we finalize our decision.

I was speechless.  “I’m not sure I understand, sir” I said. “Didn’t you just say that you liked the design?” I pointed out that none of the participants had found any flaws in my proposal.  “Why”, I asked, “did you think we need to develop two additional designs?”

He paused for a moment, and then said, “You never know what the best idea is unless you compare several good ones side by side.” I nodded politely, but I was disappointed. I felt like this was probably some form of engineering hazing. Was it truly the case that it’s impossible to achieve reasonable quality on a first try? I didn’t really understand how valuable his advice was until years later.

Yaacov Apelbaum-Pre-Stressed Concrete Bed

Completed pre-stressed concrete beds

Fast forward several years. I switched from civil engineering to software development.  At the time I was working as a lead front-end designer.  One of our key customers hired us to migrate a large VC++ client to a browser application.  In the mid-nineties, rich browser based clients were relatively unheard of.  We were stumped. Problems like session security, persistence, and lack of basic GUI controls seemed Insurmountable.

During meetings, I would regularly sketch various GUI solutions.  But I often found that as soon as I came up with a solution, a new set of problems would be exposed and a redesign would be necessary. In retrospect, most of the ideas I came up with at the time were sub-par. But with each design, no matter how bad, another potential solution was discovered.  Each new design I sketched out was closer to the solution than its predecessor. Even the poor designs peeled away some layers that obstructed the problem that I didn’t initially see.

After dozens of attempts, I had an epiphany and came up with one design that it was possible to implement in several ways. Sketching and contemplating the various designs helped me tremendously, but when the time came to present my solution, I made a tactical mistake. I deliberately neglected to show all of the other working ideas for fear that they would think that I was a mediocre designer; why else did I need to work so hard on so many designs just to yield one single decent one.

I realized in retrospect that there would have been any number of acceptable designs and by not presenting some other ideas I considered before arriving at the one I chose, I short changed myself. If anybody had suggested one of the other options I had discarded but not mentioned, I would have had to explain that I had already discarded that idea. But at that point , it would jeopardize my credibility because it would look as if I was only trying to brush them off.

 Yaacov Apelbaum-Poor Design   Yaacov Apelbaum-Quality Design M1917

Multiple product designs

After participating in and leading many painful design meetings, I have come to the realization that the best way to sell the top design idea is to first share some of the alternative and inferior designs.

If you are responsible for usability or user interface design, you have to develop at least several alternative options for credibility purposes. By that I don’t mean that you should become a cynic and create duds just for the sake of generating volume. The alternate ideas have to represent meaningful and functional choices.

Once you have your alternates worked out, walk through the various options during your design meeting and call out what the pros and cons are for each and what the overall solution trade-offs would be. When discussing designs, place emphasis on both the positive and negative qualities of each alternative.  This will help your peers view you as an unbiased and professional presenter.  Also, you may find that when you present your top candidates, your team will come up with some hybrid solutions that otherwise would have been impossible to generate if you had only presented a single one.

Nowadays, I am often tasked with working on problems that are exceptionally difficult to overcome (with respect to both technology and schedule) and the typical, off the shelf solution is just not sufficient. But there is hope. Usually after a few days of intense interterm deliberations complete with often heated exchanges of alternate designs, magic happens.

My secret sauce for breaking down the most difficult design problems consists of the following steps:

  • Get your entire team into a conference room, order plenty of pizza and write down all possible solutions on the whiteboard. Make sure that everyone offers an opinion. Don’t make any go-no-go decisions during your first meeting; rather leave the information on the board for several days (don’t forget to mark it as ‘do not delete’)  and schedule a follow-up meeting. Tell everyone to document the pros an cons list for each option and provide specific use cases.
  • Get your team into a conference room a second time, order plenty of pizza and write down the pros and cons list for each choice.  Boil down your choices to the top three candidates.
  • Work out the feasibility of each of the top three candidates and cast a vote for the best one.  This is the time to establish consensus and a team buy-in.

Way back when the chief engineer asked me to come up with two additional alternate designs, he was in fact telling me that no matter how talented a person is, there is tremendous value in variety.  He was also saying, that in order to come up with a ‘good’ design there must first be several inferior ones. If you are responsible for the design of any product futures, you will want to encourage your team to flesh out the bad designs on the whiteboard or as POC, not in your final product.  Unfortunately, the only way to achieve this is by expending resources and time exploring several possible solutions, up to and including some unattractive ones.

A common development folly (see It’s Good Enough for me) is the notion that there is in fact a ‘best’ solution or one right answer to a given problem.  Actually, the opposite is true. Considering time and resources, in most cases, the ‘best’ possible solution isn’t worth the effort and a ‘good’ solution would more than suffice.

If you are curious abut which design I ended up using for the prestress pile beds, it was the third one.  It turns out that unexpectedly, after I reconsidered the problem again, I realized that due to the yard’s location at sea level, the water table was too high to accommodate my initial proposal. As a result, my updated design required various modifications in order to solve this problem.

Live, design and prosper.

 

© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

Crafting Great Software Features Part-1

Yaacov Apelbaum-Useless Technology  
Driver’s Entertainment System and Password Protected Gear Shifter

Trying to do anything well is difficult. Developing useful features is no different. It takes more effort to create useful functionality than to produce eye candy.

Good feature design comes from a reliable and repeatable process (not dissimilar from CMM). Unfortunately, many organizations still have not figured this out and instead of investing in usability engineering, they slug it out in isolation and tragically, like Sisyphus, doom themselves to getting the wrong functionality and spend eternity (or until the project is canceled or runs out of money) patching their mistakes, version after version.

If your goal is to build a useful product, you should schedule your project so you can develop the needed functionality. Habitually excusing yourself by claiming that you “just don’t have the time” to develop quality is a cop-out. If you find that your team is spending a significant amount of time on feature seesaws (taking them out-putting them back), it means that you’re not planning well, and that the technical goals are not aligned with the product objectives.

Feature Framework
In a functional development organization, everyone should fully understands how their individual contributions will impact the end user. To help achieve this, there should be a feature framework in place.  The feature framework  must cross organizational lines and bridge development, PM, product planning, sales, and marketing.  The chief purpose of the framework is to determine what challenges end-users have and how a proposed feature, functionality, or technology will solve those problems. Without utilizing some degree of Feature Driven Development, you stand the risk of creating features that may look great (like password protected gear shifter) but solve no real problems.

Management Knows Best, Well, not Always…
In order for you to master the product usability question, you have to conduct real life tests with real would-be users. Talk to your customers about their pain points and ask them what they love (and hate) about your product.  The earlier you get the bad news, the better you’ll be in the long run.

Keep in mind that most failures in software usability can be attributed to poor decisions at the executive level, which are promulgated due to a culture of silence. Developers and designers should be encouraged to think critically about their work and be provided with official channels for expressing their opinions (in a non polemic manner).

Make sure they talk to the the other members of your team to broaden their horizons.  Invite their participation in every feature conversation. When considering new or revolutionary UI changes, solicit input from your customers and your organization.  Without sufficient end-user, business justification, and sales input, its easy to develop functionality that universally disliked (like the notorious Microsoft Clippy feature).

One of the most common development failures (after underestimating feature complexity and the cost and time to develop it) is the inability to correctly define the problem space and instead to develop solutions that are looking for a problem.  If the project objective is vague and not granular enough, it’s impossible to know whether it has been solved or not. Furthermore, even if the objective is well defined, you may still be working with the wrong assumptions about what the customer really needs.

A video screen built into a steering wheel that plays looped safety movies won’t help your user drive any safer. These two types of problems—vague objectives and the wrong assumptions—have nothing to do with your team’s technical ability. If you can’t side step these kinds of issues, even the best software engineers and designers are bound to fail. You may write great functionality and create whooping UI, but if you can’t solve the right user problem, all of your hard work will be wasted.

Do you have a Problem with That?
The first step towards critical feature analysis is to take an objective view on the nature of the problem. As a developer, you are inherently biased towards the value of your features and suffer from a certain degree myopathy. You’re inside the tech bubble looking out and so you cannot possibly see your creations the way your users do.

Yaacov Apelbaum-Team Structure To improve visibility, you need to supplement your view with external sources. These should include: UI team, technical developers, product business champion, actual customers, sales, training, and marketing.  Get as many alternative views as you can. Again, make sure to talk directly with the users effected by the design, Don’t take single  camp’s word for what the problems are. Think of yourself as a newly elected congressman trying to keep your constituents happy. Don’t only consider the opinions of the power lobbyists.

Another challenge is that the way approach your customers for feedback will impact the type of information you get from them. If you unintentionally bias your questions, you’ll get skewed data. The art of observing and understanding customers needs is an acquired skill and it may take several trial runs before it’s honed.

When researching the problem, keep the following key questions in mind:

  1. Who are your user’s, what are their skills and job functions?
  2. What is your user’s workflow and how does your product enhance it?
  3. Do your users use other products to supplement your app?
  4. What business assumptions are you making about your users and their environment?
  5. What are your user’s specific deliverables (spreadsheets, reports, presentations, etc.)?
  6. How do your competitors solve the same problems you are working on?
  7. What is your user’s strategic information roadmap and how does your app fit into it?

If you don’t have complete responses to these questions, you cannot start to design or develop any features or functionality. a solid understanding of your customers and the answers to these questions form the foundation of your application.

You Only Get One Chance, So Chose Wisely
As you are preparing to work on your next version, you will discover that there is an infinite number of issues that need solutions and a mile long list of most have features. But just having a raw list of bugs and features isn’t enough to build a product.  As it goes in life, some problems are not worth solving once you consider their poor return on investment and time.

Often, a solution to one problem spawns multiple new problems (and bugs). You need to exercise good judgment, which means having the ability to distinguish what should be done from what can be done. After collecting the business requirements, the next step is the development roadmap. You have to synthesize the requirements and create a specific action plan for where to invest your time and resources.

With the data collected from customers and internal sources, distill the information into short one-sentence lists. These sentences should be written from the point of view of your end-user. For example, “Enable password field to accept 11 characters” is not a problem statement. But “Password field must support strong passwords” is. The difference is significant. You rarely want to define the solution and the problem in the same statement: If you do, you’ll miss the real problem.

In this example, there may be many other ways to solve the problem of password strength, including hard coding the logic to accept 11 characters. But if you are too focused, you’ll never see the alternatives (make the password length database driven, integrate it with LDAP, biometrics, etc.). Good feature development is all about understanding your alternatives.

Yaacov Apelbaum-problem to a solution

A solution looking for a problem

For each problem statement, provide supporting information. Include details about which users have the problem, how it was discovered, and what the potential workarounds are. Determine whether the problem only occurs in certain configurations. Following Feynman’s rule of scientific integrity, provide as much details as you can to allow others to confirm or challenge your assumptions.

If you’re the owner of the usability study or market research data make it available to everyone.  Don’t ask anyone to “trust you”. The more open you are about your feature sources, the less likely it is that people will suspect you.

Hold your Fire
Only start coding when you see “the whites of their eyes”.  When the goals are set and the problems to be solved have been well defined and understood, you can begin to build the features. Instead of adopting a top to bottom approach (where the development team is told what to do), engineers and UI designers should have free rein to generate the ideas that will solve the problems. Time should be allocated to investigate different alternatives that might provide the necessary functionality, and to run usability studies on prototypes to see if they actually improve the end-user experience. Only once you evaluate all your potential solutions and pick the best one can you engage in full speed development. The rest of your solutions do not have to be disregarded; you can shelve them for future releases.

As long as you are working within a feature framework, you are guaranteed to be marching in the right product direction. There should be a lot of innovative and creative juices flowing in your team, and even if you can’t completely solve all of your feature functionality challenges, a partial solution to the most important problem will still be superior to a perfect solution to the wrong problem.

 

© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

Bells and Whistles

Bells and Whistles

Several weeks ago, my car’s dashboard informed me that I would need to “check the engine”. Naturally, I promptly brought the car to the dealership. After a quick examination (and $170 in troubleshooting fees), the dealer told me that there was nothing physically wrong with the car and that the message was due to a software bug that was easily fixable with a software patch that he would be happy to apply for as little as an additional $120.

Now, I don’t know much about the latest trends of engine design, but I am quite familiar with software bugs. Over the years I have produced several of them myself and like many other software engineers, I spend a certain amount of my waking and sleeping hours chasing them around. But contrary to my trusted dealer, I fix my bugs—to delight of my customers—at no extra charge.

Being the pedagogue that I am, I seized the opportunity to educate Randy, the senior service adviser (the title on his tag), and proceeded to deliver a short and upbeat oration on the subject of the software industry’s best practices regarding free bug fixes. My friend behind the counter seemed unimpressed and reminded me that his dealership is not in the business of selling software. He then inquired about my preferred form of payment for the pending repair.

On the way home I got to thinking about the cutthroat business model that the car industry is following. Clearly, it must be the competitive nature of the industry that forces them to squeeze profit at the margins to included even basic service like fixing their own bugs. I then dismissed any further thought on the subject. Then a few weeks ago, the news broke out that the car industry had officially joined the federal hand-out program. It was now standing on-line with a tin can in hand and singing in harmony “Brother, can your spare a dime?” with all the other financial industry hobos.

So I figured that there has to be something here that doesn’t meet the eye. Why has such a well lubricated and fabulously successful industry suddenly collapsed? Contrary to the financial sectors, their operational and risk models have not significantly changed for over 100 years. Cars today are designed and built faster than they were 40 years ago and they are cheaper to manufacture and sell.

After pondering this for a while, I realized that this failure has been long in the making and just like in many active Ponzi schemes, this one has been finally flushed out when consumer spending came to a screeching halt.

In the aftermath of World War II as manufacturing was going civilian again, the car industry more than any other sector embraced a strategy that focused entirely on building a product with the highest degree of of obsolescence (an average car would be recycled every n years) and greatest curb appeal. Traditional engineering principles like safety, longevity, efficiency and environmental friendliness were sacrificed. They were replaced with a lot of chrome, increased fender size, overpowered V8 engines and pink leather. This was the wisdom of the time; you can’t charge higher prices for less car.

In the 70’s, when the Japanese car manufacturers finally introduced a new concept of vehicles very different from the traditional tank, domestic car manufacturers after much soul searching, publicly embraced the banner of the new smaller more efficient car. In reality, however, they continued to practice the same philosophy as they do to this day. So in fact, not much has changed. Yes, the large fenders and chrome bumpers are gone, but in their place we have a whole new list of bells and whistles. Apparently, the car manufacturers have been taking lessons from the software industry and are now playing the feature functionality game.

Go to any domestic dealership and you are guaranteed to find the following list of “key” features:

  • Rain-sensing wipers
  • Heated/cooled seats and cup holders
  • V8 with extra torque
  • Extended Length
  • Remote starter

What is noticeably missing from the list is an engine and transmission that are guaranteed for 300K miles or the 80 mpg gas efficiency, both of which are easily achievable in this day and age.

Unfortunately for all of us, the car industry has spent the last 60 years mastering the fine art of consumer psychology and honing of their salesmanship skills with too little time spent on developing quality products.

Thank you very much, but I’ll have to decline! Contrary to what the focus groups are saying, I don’t need a Hummer. And no, throwing in a free electric cup warmer is not going to change my mind. I am, however, interested in a bug free safe electric car that can go 400 miles between charges if there are any takers.

© Copyright 2008 Yaacov Apelbaum All Rights Reserved.