Follow Along

  • Learning From Your Product Before It’s Built Part 2

    by on April 18, 2012

    (Cary Betagole writes in to tell us more about early lessons learned building a startup with partner Jonathan Kriner)

    I would compare our decision to build a product before thoroughly defining its scope to an attempt at walking through your own living room with the lights off.

    The shag carpet between your toes means you’re in the right room. You won’t run into the sofa or the armchair—they’re always in the same place. But the ottoman usually hovers near the middle of the room. It just floats there for anyone on the sofa to move and prop their feet. Today it’s abnormally close to the edge of the carpet, and you just stubbed your toe on the way by. Or worse yet, your teammate moved in two more ottomans overnight and you just tripped and knocked over the lava lamp. That’s going to be a hell of a cleanup.

    To nail all proverbial ottomans to the ground, we’re mapping out process flow charts, informed by a pattern library and business rules. If multiple members of your team are calling the same feature by a different name—nail down that ottoman. If you’re using a freemium business model, and multiple mock-ups display conflicting user limitations—nail down a decision. Set your scope in stone. Consistency is key, especially if – like us – you’re contracting out a demo.

    A few months back, my business partner Jonathan and I decided it was a good idea to prove our concept by outsourcing a demo—we’re working on a social project-planning tool to help bands connect with their skilled fans. So we scribbled down the general gist of our requirements, shared a few mock-ups, and explained our site to the offshore team through a series of conference calls. We were essentially dumping a pile of chairs, lamps, and throw pillows into the corner of our living room, and leaving feng shui up to them.

    The strategy resulted in frustrating miscommunications with the development team, and a realization that Jonathan and I were miles apart on many features the site needed to operate seamlessly. A testimony from onstartups.com accurately foretells our narrowly avoided fate, “A year ago I outsourced a website to be built. Went into it blindly, failed miserably, lost tons of money.”

    So we’ve changed our mentality. We aren’t contracting out the minimum viable product; we’re conducting the construction of our minimum viable product, by taking charge of defining modules and deliverables. As we move closer to kicking off development, we’ll focus on attributing time variables to carefully assembled modules. But at the moment, we’re focused on managing our site’s high-level design by rigorously documenting its data flow.

    First we built a pattern library to account for every little function we wanted to include in the initial version, while simultaneously consolidating features to create functional conventions across the website. By developing patterns in functionality—e.g. all Project Archives are stored on the Band’s Profile—we hope to make the product more intuitive for our users.

    During the idea stage, a product is particularly susceptible to sprawl. In line with our brand, we’ve planned to implement a cross-promotional B-side strategy, where a user who downloads a song receives an additional song from another band for free. Nice and simple enough. But soon we got carried away, and began brainstorming more crafty cross-promotional strategies, including one that allowed smaller bands to advertise on the pages of bigger bands. This was all well and good, but we had lost sight of our supreme mission—to provide bands and fans a vessel for collaboration.

    We’ve positioned ourselves as an organizational tool, so we’re prioritizing a messaging feature, recommendations feed and market research metrics for the first version, while pushing more peripheral content hosting features to the second version. By uncovering trends, and prioritizing features, our site has organically broken itself into more manageable modules.

    After sketching a layout of the living room, it was time to begin developing our business rules, which basically meant performing walk-throughs in pursuit of uncovering every single impediment.

    We attacked our business rules by creating a series of If-Then statements. You’ll have no concept how many Ifs your site leaves unanswered until you’ve ruthlessly vetted the product. For example, “If I want to check how much money a band has made, then where do I go?” Or, “If I want to change the amount of songs a band can upload, then what do I do?” As a result of asking the aforementioned questions, we realized we’d made major gaffes that could be fixed by building out a reporting panel and an administrative panel. In other words, we caught the lava lamp just before it shattered on the floor.

    On the other hand, answering the mundane questions can be just as important to long-term success. For example, “If a user registers a false email address, then…what?” “If a user enters four digits for his zip code, then…what?” The answer: the system should reject set user. If we hadn’t answered these basic questions, we would not be able to accrue data on where our users are from and how they’re finding the site.

    Our six-person team all met up in Arlington, Va. a few weekends back to eat chili and convert our business rules into process flow charts over a hardy 12-hour day. Putting our site in ink only encouraged healthy debate amongst teammates and growth in the product. It was the first time our graphic designer Kelsey had met our technical advisor Nick in person. So we poured over each business rule one at a time, as Kelsey examined UI details in depth, and Nick designed the logic and process flowcharts, while making recommendations to ensure a data-driven site.

    We also want to design the logic in a flexible way that won’t inhibit future growth. Creating data-driven features means you don’t hard-wire features into your site that will make it more difficult to iterate later. Create X-Variables. So instead of us putting in stone that we’re going to allow a band only five spaces for log-ins on their account, we can govern that number from the Admin Panel and iterate according to user feedback.

    We want to turn the lights on now, so later we don’t trip.

    Catch us out at Indy Hall, a Philly Tech Meet-up, in Little Berlin, or out at a show in Fishtown. We’re down for a good conversation.

    pixelstats trackingpixel