Fallback Icon

Development

How to Manage Product Development Expectations to Be Part of the 50% That Succeed

By: Robert Wallace

So you’ve got an idea for a software or app, where do you go from there? Do you work with your in-house team or do you seek an outside product development firm? If the latter, how do you find the best one and what should you expect in working with them?

Scott Williams, Director of Software Development at Tallwave, and Ed Borromeo, Chief Operating Officer at Tallwave, share answers to these questions in this webinar and in the responses below.

Once you have an idea for an app or piece of technology you want to build, at what point should you seek out a product development team?

Ed: Immediately. Start seeking to understand what it would take to design and build in the most capital-efficient and smart way possible. And that’s whether you have in-house or outside.

When should you go in-house versus working with an outside team?

Scott: Always own the core of your product. I can’t emphasize that enough. My favorite example of this is Periscope—the app that let’s you live stream video from your phone. They could have used an off-the-shelf system to build their infrastructure, but hired for and built their own video streaming solution. This means that they are masters of their own destiny; if they need to tailor it to suit a new business need, they aren’t held up by the limitations of somebody else’s product.

Ed: There are a lot of variables that can influence this, such as budget or where you are in your stage of growth, size, or scale. So, these considerations should be made. However, one other thing to consider is whether you’re creating net new, solving a complex problem, or you’ve had something that needs a fresh eye. In these instances, I’d ask for an outside team to help. Then I’d insource steady-state, ongoing, support/maintenance, or minor enhancement activities.

As the manager funding or leading the project, what should you look for in a product development team? What are some qualifying questions to ask to vet potential candidates?

Ed and Scott: You want to find out about:

  1. Their qualifications and level of experience
  2. Their track record and history, such as the nature of clients and projects they’ve worked on
  3. Whether they’ve presented to stakeholders before
  4. How they react when presented with timeline crunches, requirements conflicts, or competing priorities, etc.
  5. How they prioritize
  6. How they take the user into consideration
  7. How they communicate with product owners, the business, etc.
  8. How flexible they are. Be transparent about how you operate and whether they can deal with that, adapt to it, and perhaps influence change
  9. What happens when something unexpected occurs?

Often, product builds will be delivered in phases, so what should you expect out of an initial scope of work?

Scott: Planning is tricky. Doing too much of it wastes time, but too little enables too much wandering in the wilderness. Break it out into chunks as much as possible. Go with design prototype first that is validated with real people; then write out all the storycards and a technical requirements document. This is where you want to take the time to explore all build options (for cost forecasting). Then you’ll build the MVP.

Ed: Initially, you should expect to come out with the minimum need that will create a product that will:

  1. Drive the main metric or outcome you want and the user wants (minimum “viable” product)
  2. Cause people to stick with it (minimum “lovable” product)

What should you expect of your product development team?

Ed: You should expect that they have data and a point of view to back up what they believe should go into each phase, particularly the first phase when you’re taking into account market, user, and stakeholder data. Be sure they can align on the timing and protocol for communications and expectation management, and that they are transparent in their communication. Finally, they should also understand your goals as a business and be able to put on their business hats. As a business owner, division leader, founder, etc., you ought to continually educate and remind all team members of how the product fits into the business.

Scott: Demand the beginnings of the roadmap, backlog, and sprint plan—which should come from the storycarding process.

What are some tactics for working with a product development team that will optimize the process or increase chances of success? What are some pitfalls to avoid?

Scott: Don’t over simplify or be too literal. Be informed and an active participant in all phases, particularly the front-end requirements definition. Make small investments at a time, and actively participate in the reviews and scrums. Don’t fall into rigidity—be flexible when things don’t work. This will help you optimize for future speed and agility.

Ed: Specifically, teams don’t like the ground moving beneath them. So be careful not to be changing requirements in real time, mid-sprint, or simply out of preference. I recommend to really stay true to user-driven, data-driven, “lean” approaches when it comes to deciding on requirements. And stay true to your backlog and roadmap process. Of course things have to change now and then, but let the process surface that to the greatest degree.

Finally, I like to speak in terms of outcomes and user needs, and continually reiterate those. I believe that if product teams know the business outcomes and user problems we’re solving, and you deliberately and explicitly have them share control of those, it helps tremendously.

Written by Robert Wallace

    Want more?

    Get extra insight with our newsletter.

    In the media

    We’ve shared our secrets with…

    Inc Entrepreneaur Press & Media