Steven Kury: Digital Product Management, User Interface Construction

How to Make Digital Product Enhancements

I was recently asked how I would go about making enhancements to my favorite Internet/phone app. How would I approach it? What would my process be? I thought it was an interesting question to consider, as there are both good and bad answers to it. It must be done methodically and strategically, or else a product management team can easily set itself up for frustration further down the line as the product grows in unuseful ways.

If I were product manager for a web app of my choice, it would not matter what my app of choice would be. I would approach its enhancement in the same way. I would start out with a “product discovery” phase. (This is the methodical aspect of the approach.) This would entail meeting with the customer success and marketing teams to find out which aspects of the product customers voice frustrations with and/or a desire to have. Whether it is 1) a request to simplify a feature to have a more delightful user experience (UX), 2) expand upon one to be more robust, or 3) create a new one in its entirety, enhancements have to originate with customer desires.

When resolving frustrations with the product, my intention is not to work with users’ stated suggestions to “make it do this...” It is to dig in to discover their fundamental problems with it, i.e. their actual pain points and the results that they want to see that they aren’t. Based on these understandings, the product team can deduce the real problems and devise solutions to them.

If it is driven by my personal desire, or the CEO's, it may not enhance the user experience at all, and thus not enhance its saleability or reputation. Preserving the saleability and reputation of the product is one strategic aspect of the approach.

In the meeting with the customer success and marketing teams, I would catalog all of the potential enhancements, and prioritize them by apparent customer value. Sales and marketing would also consider which of the options might have strategic value outside of satisfying the immediate customer desires. An option that satisfies higher level strategic business objectives as well as the customer desire would rank higher than one that only satisfies the latter. (This is another strategic aspect of the approach.)

After vetting and prioritizing the enhancement options, I would consult the following stakeholders in a "due diligence" phase:

  1. Art/UI and UX – to vet the UX implications of the enhancements as well as the visual design requirements. In some companies, art/UI and UX are the same team, in others they are separate. I want to know the expected effort for each option, as well as make sure that it is handled in a way that can be expanded upon later if need be. It is also important to consider the UX input up front rather than later in the process, when it is harder to incorporate.

  2. Engineering – to obtain estimates of their involvement, as well as risk levels and “two birds with one stone” considerations. If there is any possibility of writing code so that the same functionality can solve multiple options for enhancement, it would be good to know this. The risk levels would primarily deal with whether the changes would be isolated or system wide. A system wide tweak is risky and needs a greater amount of testing. Such a tweak should be avoided in the 11th hour of a greater release.

  3. Quality Assurance – to obtain estimates of their involvement, as well as the risk levels of the proposed changes. (This could easily be part of the engineering meeting.) They might prefer to do a limited release of each enhancement, to test it live and ensure that it functions as expected, before giving it a full release. This would be my expectation.

  4. Development operations (release management) – to obtain estimates of their level of effort for each option, as well as understand the level of intensity of upcoming releases that are already in the works.

  5. Localization – to obtain estimates of their level of effort. While their contribution to the enhancements would be rather straight forward, they only localize strings, they would likely appreciate being consulted for their involvement.

  6. Finance – finally, to obtain their assessments of the affordability and “bang vs. buck” of each enhancement option. I don’t expect simple enhancements to warrant anything as involved as an NPV analysis, but that is up to them.

With each team, not just engineering, I would ask 1) how full their plates are currently, 2) the order in which they would prefer to do these enhancements in, and 3) their expected timelines for them. From my prior experience working with these disciplines, I could infer the level of interdependency existing between the teams. For minor enhancements, I would work with general expected timelines. For higher risk gambles, which would be more involved, I would ask for best/reasonable/worst case timelines and consider the implications for each.

Throughout this process, I would expect each team to ask 1) why we are doing these enhancements, 2) how time sensitive are they, 3) and how interdependent are the other teams on them?

After the "product discovery" and "due diligence" phases, I would prioritize the top three low risk quick fixes as well as the top three higher risk gambles. (The higher risk gambles are probably more involved than the quick fixes, with system wide ripple effects.) I would prioritize them according to their level of involvement as well as financial and strategic value.

Finally, in a meeting with the senior management, I would first pitch the low risk quick fixes that the customers desire, and go into the gambles if they aren’t quick to bite on the quick ones. From this meeting, their consensus might be to go with the first two quick fixes. This might be because they share a “two birds with one stone” factor as well as being valuable to customers individually.

Senior management might forego, for now, the bigger gambles because the development and QA resources are committed to other initiatives under tight timelines. (Only the two smaller options can be squeezed into the current workload.) In addition, the marketing team may not be prepared to address them publicly.

With this decision, I would return to each of the teams involved with the “go” and set the wheels in motion to make them happen. Based on each team’s current work load, we would plan on working these two enhancements into the next feasible release cycle. I would advocate releasing them on a limited basis. Once they are verified as stable, then I would release them fully.

While this process would play out differently in different organizations, with differing team structures, it would be essentially the same. It start with the "product discovery" phase, where enhancement options are refined from actual user desires and frustrations. Following this is the "due diligence" phase, and finally the pitch to upper management for the selection of enhancements to develop. The process is methodical so that enhancements provide immediate value to the product's users as well as higher level, strategic value to the company.

. . .

Steven Kury, MBA, is a software product manager. Throughout his career he has contributed vision and leadership to a breadth of online applications. Contact him at or (717) 350-6781 to discuss how he could contribute to your system.