###############################################################################

      *****************        Hey! Welcome to the Kwoosh Workshop
     *******************       -----------------------------------
    *******  *****  *****
   ********  ****  *******     This is where we talk about the things
  *********  ***  *********    we're working on.
 **********  **  ***********
***********     *************  Most things start as messy ideas before
 **********  **  ***********   they get polished into finished features.
  *********  ***  *********
   ********  ****  *******     This is a place for messy ideas.
    *******  *****  *****
     *******************       For the completed product see kwoosh.com
      *****************

###############################################################################
                

Everyone's on the product team

Many large software organizations split their teams into functional teams: designers doing design, system admins doing operations, developers writing code, and product deciding how the product works.

The idea is simple: let people do what they’re best at and you’ll have an efficient team doing what’s best and in the end you’ll have a coherent product. Product thinks of a new feature, takes it to design to design, who then works with the developers to get it made a part of the product.

While this may result in a product, it also results is a team with large siloed blind spots. Product only sees the tip of the iceberg of that new feature and design makes the feature fit as well as it can, saving it’s energy to fight for another day. After everything’s been decided the work is then passed off the development to make it work.

As a developer it’s easy to acquiesce and just build it thinking, “Hey, I’m doing just what they told me. And besides, it gives me an excuse to try out this new library”. We then try to pass the blame of a poor product off to the product team - afterall, it was their idea.

However managing software is a developer’s job. They’re the only ones with a full sense of the “how” the entire thing works, so it’s up to them to make sure the product doesn’t become compromised. You wouldn’t let a home buyer insist on changes that would compromise integrity of the building and software is no different.

Below are three questions you can ask yourself and your team to help figure out if you should include that new feature in your product.

Is this a core competency?

Are you asking a bear to ride a unicycle? Sure, it may technically be possible for a bear to ride a unicycle, but it doesn’t make sense. Are you building photoshop into your CRM so people can crop their profile photos? If feature play doesn’t play to a core strength of your product, leave it out. The feature will be half-baked at best. If you must include the feature outside your product’s core competency, try offloading the core to a third-party tool whose core competincy is that feature and integrate OR reduce the scope as much as possible.

Where does this feature belong?

Where does this feature belong and how does this fit into the user’s workflow? It’s all too easy to just create a menu for “orphan features”, features that don’t really fit anywhere in the app, but are being shipped anyways.

Ask yourself what users will be doing and what kind of urgency they’ll typically be feeling when using a given feature. If you can’t come up with a better location than the orphan menu, it may be best to leave the feature out until you can.

Who’s going to use the feature and how often will they use it?

Who’s going to use this feature and how often are they going to use it? Is it a report they’re going to run daily? Or is it something they’ll run once when first start using your product and then rarely after that? If it’s something people are going to access often, make it easy to find.

—jvd