Upgrade to Pro — share decks privately, control downloads, hide ads and more …

UseCase.org | Prioritizing to move from bug-fixing to NPD

Alpha
July 08, 2015

UseCase.org | Prioritizing to move from bug-fixing to NPD

How do you align competing internal customers' priorities so that you can get out of reactive and troubleshooting mode and into NPD/NFD, product discovery, and innovation rather than "fixing bugs”?

Alpha

July 08, 2015
Tweet

More Decks by Alpha

Other Decks in Business

Transcript

  1. Question of the week How do you align competing internal

    customers' priorities so that you can get out of reactive and troubleshooting mode and into NPD/NFD, product discovery, and innovation rather than "fixing bugs”? Submitted by: Anonymous Product Manager at Nasdaq Perspectives from Molly Barton Josh Wexler THE PRODUCT COMMUNITY Thor Ernstsson
  2. Read more best practices on Usecase.org Josh is an expert

    on early stage software innovation. As a Solutions Director at Originate, he develops new business and helps potential partners shape their ideas into projects. He has advised global consulting firms, financial services companies, and early-stage entrepreneurs throughout every stage of the software development process, ranging from ideation and validation to fundraising rounds and commercial launches. JOSH WEXLER Josh’s Perspective I think those are two fairly different questions. To answer moving from bug fixing into new product features, I think it really depends on where the product is in the lifecycle. At a beta version, you need to keep iterating. But once you hit versions 3 and 4, maintenance becomes a large part of its success. For people at version 5 or 6 of their product, typically if there has been a team working from 0 to 5, that team really likes to start on new products and features. You need to think about bringing in and transitioning to a dedicated maintenance team. Another question is process. There are processes that are geared really well for early stage product development, like Agile. But when it comes time to maintain a product in the market, there are other methodologies out there that are based on traditional manufacturing, like Kanban. That’s really the big difference - maintenance is never done while a release is done. There are ways to make maintenance feel more release driven, but even if you try to, it’s kind of forcing it. Stop saying one more sprint of bug fixing - it’s never done. That’s what Kanban does. When it comes to competing customer priorities, that’s going to depend so much on your particular organization. I could say you should do a matrix, and sure that might be helpful. But bottom line is it comes down to: read the politics of the organization that you’re a part of and the customers you serve. Often times the most important person is asking for something stupid, and you have to say no. A matrix won’t help you there. In that one case, you have to maneuver around that. Just be thoughtful and reason it out - there’s not necessarily a formula for this.
  3. Thor is the CEO and founder of Alpha UX, a

    real-time user insights platform for Fortune 500 product teams. Previously he was the CEO at Casual Corp, a social product studio in NYC, and before that he was a lead architect at Zynga and CTO of Audax Health. THOR ERNSTSSON Thor’s Perspective Ideally this issue is addressed by clearly communicating a vision for the product to all stakeholders and teaching them to seek validated learning over simply building more features. However, this requires exceptionally high-performing teams and is often impractical because of internally-conflicting priorities. Clearly defining goals and objectives for product iterations is a good tool to get short-term alignment of priorities. Sometimes new features, validation, or user discovery work becomes a lower priority than the burning problems that must be addressed immediately, but at the very least it's an explicit part of the conversation. Aligning multiple stakeholders will always be a balancing act, but a critical one for a successful product manager. One very useful method to make sure you're pushing product discovery forward is explicitly incorporating user feedback at the same level as other internal stakeholders. Some managers have famously added tokens of user feedback into product conversations, such as Jeff Bezos's empty chair to represent the end user. Every organization is unique, but its problems are often very common. Learning to communicate in terms of experiments and user outcomes can cut through many of the internal competitive issues and push the users' unmet needs higher on the list of priorities. Read more best practices on Usecase.org
  4. Barton has held marketing, editorial, business development, and digital strategy

    roles at Oxford University Press and Penguin, the world’s most recognized publishing brand and one of the world's largest English- language trade book publishers. Most recently she was Global Digital Director at Penguin Random House, reporting to the worldwide CEO and leading the digital business. MOLLY BARTON Molly’s Perspective To get out of the rut of chasing bug fixes, you've got to institute disciplined and well-structured collaboration between Product and Engineering. But depending on the state of your existing product, you may first need to hold a 'Fixathon' over the course of a week to clean house and address the most aggravating issues. The head of Product and head of Engineering need to establish a process of balancing fixes vs new product---the broader team can input requests and feedback, but the decision-making process about what gets fixed immediately and what gets added to the backlog needs to reflect the overarching business goals. Are you just gaining the trust of early users or are you positioning the company for an exit? The answer to this will help inform the approach to fixes vs new product. Depending on the size of the company and level of funding, Engineering may decide to dedicate 1-2 developers to fixes so that existing issues can be resolved while the company is also pressing forward with new product development. Decisions about how to improve/fix existing products AND what new products to pursue should all be informed by prototypes and rapid user testing, so development hours are spent as efficiently as possible. Read more best practices on Usecase.org