3 symptoms of a diseased product development process - Parajuli
  • Breaking News

    Thursday, April 13, 2017

    3 symptoms of a diseased product development process

    Paste your parsed code here.
    Paste your parsed code here.

    Picture yourself as the head of a product development division at a Fortune 500 company. You and your team are tackling a new project that fits hand in glove with corporate’s new strategic vision.

    Unfortunately, your team’s deadlines and goals — as well as the product’s features — are all determined by the visionaries. You lack any meaningful control over the process, and the team’s only motivation comes from meeting arbitrary progress points passed down from above.

    What’s the end result? You’ve developed a product weighed down by unnecessary features that may fit into corporate’s strategic plan but don’t fit into the life of the end user. If and when the product is user-tested, what you already know will become apparent: You’ve wasted weeks or months on a product no one understands or cares to use.

    A common condition plaguing companies

    The perfect-on-paper, poor-in-practice scenario I just ran through happens every day. In fact, broken product development processes have become pandemic. These diseased processes affect companies large and small. Their most frustrating symptom is that the employees most capable of seeing the signs often feel powerless to seek a cure.

    A well-oiled product development machine produces a pared-down product with core features that users love. If your process isn’t leading to this kind of outcome, then it’s time for your process to seek treatment.

    The following are common ailments that can wreak havoc on your product development process, along with the therapies that might help.

    1. Getting caught in the cascade of waterfalls

    Most product development professionals acknowledge that waterfall development doesn’t work. Although the agile methodology is widely accepted, many companies engage in a pseudo-agile approach that serves as a poor cosmetic cover for their “hidden” waterfall process.

    This hidden waterfall approach features the outward appearance — buzzwords and all — of an agile process. There could be “sprint planning,” “sprint reviews,” or even “user stories,” but despite these magic words, agile’s substance is missing. Product decisions and releases are still passed down from on high.

    This hidden waterfall leads to burnout for employees, who are merely ticking items off someone else’s checklist. Beyond employee boredom, the product suffers because it becomes completely detached from changing technologies or user input.

    A true agile process is penicillin for this affliction. According to a report from the Standish Group, agile methods succeed three times more often than waterfall development processes, and there are small steps you can take to leave the waterfall behind.

    For example, at Yeti, I (and the rest of my team) took the critical step of embracing story point estimation. Using story points as benchmarks drastically alters the outlook of the product development team. A story point system offers a built-in guideline for planning deadlines, and because the benchmarks are meaningful, the team becomes invested in hitting them.

    Story points are just one part of the agile remedy, but they’re illustrative of the overall cure. Agile gives control to the product development team, keeps stakeholders on the same page, and, ultimately, yields a better product.

    2. Ignoring the nagging pain of feedback

    Too many companies forget to ask the all-important question: What do users think? It’s not quite a banner-worthy slogan, but all the same, it’s an ever-present question in the minds of product developers.

    What happens when developers ignore the question’s nagging twinge? The risk of product failure balloons. A company that adds features according to internal demands rather than audience needs risks finding itself with major problems when it gets around to gathering user feedback. If you’re not listening to users throughout the development process, you open yourself up to painful feedback and expensive product reworking.

    Fortunately, there’s an easy fix. Consult users early, consult them often, and continue taking their suggestions into account as you fine-tune your product. The incorporation of user-friendly features may determine whether the product thrives or goes on life support when it reaches the marketplace.

    For example, a utility tool you’re building may feature several screens for users to navigate. If you don’t prototype and test them with users, you might not learn until it’s too late that the navigation is confusing or that users become frustrated before working their way through all of them. Armed with that knowledge early on, you can change the organisation of the tool’s menus to make it clearer to the user what his or her next steps should be. More often than not, user insights light the way to transition from a flawed product to a great one.

    3. Skipping the strategic planning

    Product road mapping is like a vaccine that inoculates your process against dangerous detours. That’s not to say it’s a one-and-done shot, though.

    Companies commonly update their product road maps once or twice a year. This isn’t enough direction to offer the team the flexibility to incorporate new data or industry developments. Your plan may be six months behind market changes before you’ve had the opportunity to update your product strategy.

    Ideally, product developers are constantly learning new techniques and improving their skills. It makes no sense to set fixed deadlines on a six-month basis when six days into a project, that particular goal may be obsolete. Regardless of their roles or levels of dedication, workers can’t engage with a project they know is a proverbial bridge to nowhere.

    I saw this phenomenon first hand when Yeti recently worked on an initiative with a static road map. In between sprints, the project was losing its direction. To get it back on track, I built a shared product road map, alongside my team, that could be revised after every sprint — and we built in time following each session to do just that. The change resulted in a clear product strategy that’s flexible enough to improve with new information.

    A broken product development system will not get better without treatment. An agile process that incorporates meaningful feedback and frequent road map updates could be the miracle drug your company’s next product needs.

    Rudy Mutter, EVP of technology and founding partner, Yeti LLC
    Image Credit: NakoPhotography / Shutterstock

    Paste your parsed code here.
    Paste your parsed code here.
    Share with short URL:
    Encoded AdSense or Widget Code

    No comments:

    Post a Comment

    Contact Form

    Name

    Email *

    Message *