Deciding which products and features to develop can be challenging in a large organization.
There can be many business lines and departments with differing needs and competing priorities, and every one of them thinks their problem is the only one that needs solving.
If you try to work on everything for everyone, you could end up with many point solutions that are difficult to maintain. If you focus too narrowly, parts of the business that fall outside your focus may feel neglected, and easily solvable problems might go unaddressed.
Drawing from my own experiences in large-scale product development as a former Chief Product Officer at a publicly traded mortgage lender, I hope to provide you with valuable insights on how to identify the internal problems worth solving and select the key stakeholders to drive your solution forward.
When your team looks for problems to solve, you should only work with stakeholders whose teams or departments meet the following criteria:
The groups you work with should have a real business problem that impacts growth or wastes resources, and they need to acknowledge they have this problem. If they say things like “we already have a good process for that” or “it doesn’t really take that long” then they are not seeing it as a real problem. Don’t focus on those things.
Sometimes it can take some education to show stakeholders the extent of a problem and to explain the impact if it could be solved. If you can quantify the real impact a solution will have, they may very well acknowledge the problem.
It also helps to illustrate the “art of the possible” with technology. Because people may not understand what can really be accomplished (particularly with recent advancements in AI), if you take the time to explain the problem in detail and show the art of the possible, you could convince stakeholders to back your development initiative.
But if you do a good job with this and they still don’t think it’s a real problem… it’s time to move on.
If a problem is large enough that a team or department has searched for a third-party solution or even put together a “DIY” solution (often in Excel, and unfortunately many times using VBA), then it may justify your product team’s focus. People are remarkably adept at finding workarounds for most small problems, such that they tend to forget things were even a problem in the first place.
Many times, those workarounds solve the problem well enough that a bigger solution may not be needed in the near-term.
NOTE: In some cases, people with a strong voice in the organization may complain about a problem to an internal product team with enough passion that it sounds like a major problem.
Never confuse the volume of the voice with the size of the problem though. It’s often the case that the problem being complained about isn’t something they’ve ever put their team’s energy into solving — they might just be bringing it up to keep as much of the company’s limited product development resources focused on them as possible.
But if the problem is large enough that the team or department has searched for a SaaS product to solve it, or hired a consultant to review it, or built something themselves to solve part of it — then it’s likely a problem your team should focus on.
Even if a problem is acknowledged and understood well enough that stakeholders have tried to solve it themselves, it may not be in an area of the business that should be focused on. If the business is winding down a division, for example, it may not make sense to start a project focusing on boosting efficiency of that shrinking division.
If the strategic focus of the company is elsewhere, don’t divert limited resources to solve problems that aren’t aligned with the company’s vision. If the team, department, division, etc. that has the problem is in an area of the business with the revenue, growth or strategic focus to create a high-impact for the business, it likely deserves your product team’s focus.
Don’t forget that maintenance and improvement will always be required once a product is built. This will leave less capacity for new products. You have to choose which problems you focus on wisely.
In my experience, product teams should not work on new projects or features that do not meet these criteria. Building something for a group that doesn’t think they need it or doesn’t justify the team’s focus creates waste.
After you’ve identified a problem worth solving, how do you identify the most helpful stakeholders in each department to help you solve that problem? Here are three good ways to approach it:
If you have existing internal products used by the teams and departments you’re engaging, start by reviewing application usage data to identify your highest volume users.
Early tech adopters and frequent users should be your primary providers of feedback, so seek out the associates, managers, directors, etc. who are using the systems, templates, reports, etc. your team has built for them every day.
Reach out to department heads and ask who are the most tech savvy people on their teams and who are their most efficient team members.
There may be highly effective team members who don’t yet use the products you’ve developed—but their feedback will be key to developing strong solutions for their department. Leadership should also either serve as the primary stakeholder themselves or designate a primary stakeholder to work with us who can answer questions and make decisions quickly.
It is important to reach an agreement with team or department leadership on who the stakeholders will be for any product, as a significant portion of their time may be needed to attend discovery meetings and provide feedback.
Create a list of candidates and coordinate with management to select a group of at least five high-volume users and experts from each department. Try to get people from different teams in the same department, people who perform different functions in the same process and a mix of people at different seniority levels to provide diverse perspectives.
This list of stakeholders will be extremely critical in the development of your product, so make sure you have the full buy-in from the department to leverage their time and resources.
Once you have determined where to focus and picked a group of stakeholders with whom you can conduct discovery and ride-along calls, the scope discovery process starts in earnest.
That will be the subject of Part III in this series — coming soon!
Schedule a demo to see our multifamily analytics platform in action.
