Over the last few months I have helped a number of other projects in the office setup bundler. I’ve been using bundler with my new Rails application for the last six months and have earned a reputation as the bundler master within the office.

The fact of the matter is that, although I’m happy to help, the bundler website is so well done that my help was not strictly necessary. I’m a big fan of the large text, code snippets, succinct descriptions, and piecewise instructions. I’d say it is nothing short of negligent for someone using bundler to not read through the site at least once.

On a related note, aside from bundler, the git-deploy project has been the other piece of really awesome technology we’ve used on this latest Rails application. git-deploy makes great use of git and Passenger to make for simple and extremely fast deployments. It has also been trivial for me to add some of my own extensions to it. Some of my favorite moments have been when I’ve deployed a new version of the application to our staging system, while our tester was working on it, and have her not even notice. Big thanks to Mislav Marohnić for creating git-deploy.

Finally, here are some articles about why you should care about bundler. They are written by one of bundler’s authors.

• Some of the Problems Bundler Solves
• Ruby Require Order Problems
• Named Gem Environments and Bundler
• The How and Why of Bundler Groups

A Shared Vision for Product Design & Ownership

"Real artists ship." - Steve Jobs

As a working software designer there is no more exciting, relieving, and depressing moment than the moment you ship a product you've been working on for months. With each client I work with and each product I work on I invest myself fully. The product becomes “our” product.

If all goes well we've worked together to define features, craft experiences, and empathize with end users. We've settled into a shared vision, vocabulary, and collection of dreams for the product. Together, we've given birth to something new.

Giving that “something new” up for adoption isn't easy. Even if the client was a fully-engaged parent. Especially if the client was a fully-engaged parent. It’s these clients who will take a project and continue to push it forward even after the original designer has moved on.

The Agile development process used at Atomic Object encourages fully-engaged clients who are intimately involved in feature definition, prioritization, and the rest of the design process.

These clients are most often a dream to work with. They care, they're invested, they're informed and can contribute their depth of domain experience. And having been involved in the design process from day one they rightfully feel a sense of ownership in the decisions that have been made. They have been, and will remain, the product owner no matter how much I—as a designer—invest of myself into “our” product.

Features will be added, usability issues will be addressed, and new vision will be discovered. If the product is any good the product will change. This is not surprising and should be encouraged. The disappointing part of this is not that the client takes ownership but that some clients will mistake their intimate involvement in these decisions for design.

After launch it becomes much easier to just add this feature or that page. The shoe-horning doesn't become an issue immediately. But ad hoc features grow like weeds and if left untended can choke a product before it has a chance to succeed. In more extreme cases they can even drive away users that have already chosen the product and begin a much slower, but still dangerous, reverse tide (see Facebook's current privacy woes).

Product owners always have a hand in the design process, and even more explicitly in an Agile team. So, it is important for me, as a product designer, to help them find and begin to use a set of feature management tools that will keep “our” baby alive.

Unlike most traditional print designers, as a software designer I’m setting foundations for a product that will continue to evolve over time. And that evolution is bound to happen at a much faster rate than that experienced by other types of product or identity design. The digital world moves—and moves fast.

These foundations begin with practices that will help product owners nurture sustainable design and avoid the kind of post-design feature creep that can eventually poison the bottom line.

Here are five practices I try to follow as a product designer and teach product owners to take ownership of as they continue to move forward:

1. Ask The Five Whys

   When considering a new feature for your product consider The Five Whys. Question your feature until you’re absolutely sure that it should be added. Remember it’s much harder to remove features than it is to add them.

2. Ask Five More Whys

   If you begin by describing your feature with either of the following phrases, “It’d be cool if ...” or “Users have been asking for ...” consider asking five more whys. Both of these can be easy paths to a diluted vision. While users are important and they often think they know what they want, their vision is most often narrowly defined by what they have experienced in the past. You want your product to be focused on the future.

3. Have an Opinion

   Good product design has an opinion and usually a strong one. Only add the features you can fall in love with—the ones that seem essential to the identity of your product and make you want to get up in the morning to see if they’re finished.

4. Say Sorry

   It can be exceedingly hard to do, but sometimes you have to remove a feature or two. Be very cautions but unafraid to kill features that undermine your product. Sometimes you just have to say, “Sorry.”

5. Avoid The Creep

   There is nothing that can help you keep your product vision alive and well like awareness. Never cut corners or say yes too quickly when considering new features. Continuing to ask yourself and your team the hard questions will be key to staying on point.

Adam Hartung made a simple observation in his keynote for Energy Summit 2010: markets shift; companies that don’t follow the shifts disappear.

As an antidote to obsolescence, Adam offered four pieces of advice: be future-oriented, obsess about competitors, disrupt yourself, create and maintain whitespace.

1. Plan for the future, not the past

It doesn’t matter what you sold or did last year. Don’t plan with a rearview mirror. You have no choice but to go where the market is going, not where it’s been.

Not surprisingly, this observation reminded me of Landmark Education’s teaching about the pervasiveness of the influence of the past. Facing a truly open future is a lot more uncomfortable and more difficult than living backwards with the market we already know and have had success in. The past provides data that can be analyzed; the future requires more guesswork. The past is known; the future is unknown. The past has already rewarded you; the future includes the possibility of failure. The past has known competitors; the future may have wholly new competitors.

2. Attack competitors lock-in

You don’t get new product insight from customers. Customers tell you they want what they already have, just cheaper, faster, better. Stop listening exclusively or too closely to your customers.

Adam offered several famous examples of significant innovations that came about by ignoring incremental improvement. Apple seems to be one of his favorite sources. (Apple and the iPod, Apple and the iPhone, etc.) He also offered stories about newspapers ignoring fringe competitors like Craigslist, Ebay and Google to their peril. The seemingly fringe competitors might be the ones that disrupt your business in the future.

This was the most interesting point in that it is in apparent contradiction to the idea of user-centered design. I think the contradiction can be resolved by moving your product research a level higher. Asking a customer what she wants might not give you valuable insights. Asking her what she cares about, what her pain points are, what her goals in life are, aren’t questions obviously related to your product, but may provide insights and ideas for innovation.

3. Utilize disruption to change thinking

Don’t find yourself saying, ‘That’s not a market we’re in; we need a partner.’

Adam’s best example here was Honda. Honda has developed a medical device to assist walking. This business evidently came about from their experience building industrial robots. They recognized that a walking robot was a big challenge that would cause them to learn. This lead to ASIMO, a humanoid robot that could eventually handle stairs. ASIMO lead to a walking assistance device.

According to Adam, Honda did this work in the medical device field without a partner because they’d “never learn” if they “had a partner.” This contrarian approach reminds me of the idea of beginner’s mind and how it might explain why frequent pair rotations increase development velocity. Learning drives innovation.

4. Disruptions open white space

Adam’s final point was that established companies need to create space for disruption and innovation to take place. Part-time assignments, teams from the corporate matrix, comparisons to existing products, short-term ROI—these aren’t conducive to disruptive innovations that may ultimately be highly successful.

The title of the linked article below is approaching hyperbole. Nevertheless, a basic understanding of these two different cultural dispositions — Askers and Guessers — could have real impact on not only your relationships with your clients, boss, and coworkers but perhaps every relationship in your life.

This column will change your life: Are you an Asker or a Guesser?

... We are raised, the theory runs, in one of two cultures. In Ask culture, people grow up believing they can ask for anything — a favour, a pay rise — fully realising the answer may be no. In Guess culture, by contrast, you avoid “putting a request into words unless you’re pretty sure the answer will be yes. . . . A key skill is putting out delicate feelers. If you do this with enough subtlety, you won’t have to make the request directly; you’ll get an offer. Even then, the offer may be genuine or pro forma; it takes yet more skill and delicacy to discern whether you should accept.”

Neither’s “wrong”, but when an Asker meets a Guesser, unpleasantness results. An Asker won’t think it’s rude to request two weeks in your spare room, but a Guess culture person will hear it as presumptuous and resent the agony involved in saying no. Your boss, asking for a project to be finished early, may be an overdemanding boor — or just an Asker, who’s assuming you might decline. If you’re a Guesser, you’ll hear it as an expectation. This is a spectrum, not a dichotomy, and it explains cross-cultural awkwardnesses, too: Brits and Americans get discombobulated doing business in Japan, because it’s a Guess culture, yet experience Russians as rude, because they’re diehard Askers.

(via Bobulate)

Last week Software GR had the distinct pleasure of hosting Bob Walsh of StartupToDo.com. Bob shared from his experience working in IT for over 30 years about what it means to be IT professional in the information age. Bob and his friend Pat Foley run the Startup Success Podcast. Bob is an accomplished author, having published 4 books on startups and the business of software.

Read the rest of this entry