Diving Deeper

Building Internal Tech Products for “Non-Tech” Companies

Summary Solution: Organizations often shortcut internal tech products because they don’t provide direct value to the customer. This post explores where and how to invest your time and efforts.

Read a book or article on the topic of building a great product, and the process seems simple enough: Identify a customer base with an underserved need, present a value proposition, slap on some consumer-driven features and iterate to success. Even when we calibrate product development for an internal audience within an organization, the formula presents itself as manageable: Build an enterprise solution that solves for real problems and stop wasting time and money on activities that don’t.

However, even in the most forward-leaning institutions, the quirks of working in large, siloed organizations will often leave projects – even those carrying a great deal of momentum out of the gate – in an overcomplicated version of what appeared to be a simple formula. Though many IT teams and innovative departments may ostensibly side-step these challenges, oftentimes success is all in who is asking.

Organizations that are successful in the development of internal technology products explicitly recognize the challenges that lie ahead and use transparency and customer data as their north star. In this post, we’ll lay out several common challenges facing these product developers and provide tactics to overcome them.

Internal Products Tend to Be Stubborn

Good consumer products are often sticky. Let’s take your favorite social media app as an example. When you first discovered the app, it piqued your interest, and, perhaps over time, its value revealed itself, driving you to form a habit where you continue to seek that value.

Internal products can be sticky, too – but that’s not always a factor of the value they deliver.  Where bad consumer products are often weeded out when customers move on to something better, bad internal products have a tendency to hang around with a user base, even when nobody wants them. They are stubborn.

Eliminating stubborn products from large and complex institutions requires engagement from leadership and a self-policing and regimented product culture – not to mention a healthy bit of disposable income. Assuming that many organizations are just not there yet, it’s better to focus on employing good product development practices and making small adjustments to problem areas within your various products to ensure they work for your intended purpose. The rest should fall into place.

Internal Products Are Often Scaled Down

Internal products typically serve a small customer base with well-defined problems and few, if any, competitors.  In theory, this should simplify everything. Except it doesn’t. It makes it harder.

Fewer customers and competitors makes it difficult to judge the performance of an internal product. The lack of competition can leave decision-makers with few, oftentimes misleading, metrics (like adoption rate) that are not indicative of the product’s performance. And depending on the culture of the organization or department, doers may not be forthright in reporting issues – or subversive in their refusal to use a product that leadership appears to like. Even tried-and-true statistically based methods like A/B testing may not be as effective, given a small sample size.

The result is that leaders are left to fill the data gap, speaking for the needs of the organization with little grounding from performers. Those of us with experience in these scenarios refer to these recommendations as “HIPPOs” – the highest paid person’s opinion.

Fortunately, the intimacy of internal product builds is also their strength. While middle managers may feel close enough to their people to list out requirements (which, in my experience, are often incomplete and misleading), the customer team is also within reach and should be leveraged to provide deeper understanding. Empathy sessions are an excellent tool for getting to know a problem – even one you think you know well.

Your team may also want to spend time shadowing current customers to better understand processes and painpoints. Packaging this information into robust, well-defined personas, paired with continuous sharing of customer insights with leadership and middle-management, will not only inform your product, but should also help keep the HIPPOs at bay.

Excel is Almost Always Hiding Something

As you work your way through this process, make sure to drill down to the areas where Excel is used in the context of, or in conjunction with, your product. Excel is so often the glue that daisy-chains products together and can be an indication that there’s a problem worth solving within the product itself or one created by an incompatibility between two systems. Instrumentation – the programing that measures a product’s performance, helps diagnose errors and tracks trace information – is great tool for understanding these types of issues. It can inform developers on usage patterns and uncover insights for future iterations based on how customers are engaging with the product, where they’re finding issues, and when they’re simply abandoning a function or step.

Create a Shorter, More Effective Runway

While change in large, unwieldy institutions is often slow going, the pressure on product leads to quickly deliver value is immense. This is largely a factor of skepticism or lack of familiarity with these newer problem-solving systems and a preference or comfort with more traditional delivery methods. In order to compensate for this pressure, leads may release a subpar product as a means to meet agreed-upon schedules or budget constraints. These products may be incomplete or too inaccessible for customers to use (which product managers are quick to defend with terms like “minimally viable product” and “Agile delivery”).

Due to their limited exposure and the human tendency to want to claim a win, these products take up residence in the aura of “good enough,” as opposed to teams going back in to address shortcomings. Updates lose steam when the required investment equals that of the initial build. And ultimately, because of leadership turnover, performance cycles and customer sentiment, product leads are easily incentivized to begin work on a new problem or product rather than improving upon an existing one. But manageable pieces can be tackled incrementally. Riskiest Assumption Tests (RATs) – which test the most impactful assumptions before a product is built through surveys, theoretical demos or reporting will demonstrate need to skeptical leaders. Truly Minimally Viable Products (MVPs) that contain thin slices of product attributes to gain learnings and fuel iteration are also powerful items of persuasion. Working, useful software is worth 1,000 pitch decks.  In order to use these tools effectively, teams will need to find quick comfort in the likelihood that, while most ideas will ultimately fail, this approach will reduce the amount of wasted work when building the minimal UX required to gain realistic feedback.

Additionally, commit to a dual-track Agile approach, which will save your organization time and money. Empower product managers, designers and the tech lead to handle experiments, RATs and prioritization efforts, enabling engineers on the development team to focus on grounded work with the best odds of providing value.

The underlying complexity of building internal products makes it a discipline unto itself. But when we set measurable and realistic goals and timelines on the front end, apply an iterative spirit and are guided by organizational best practices, regardless of the organization’s innate tech savvy, development teams who leverage these tools have the capacity to build smart, hard-working internal technology products. Click here to talk with our team about helping your organization see beyond the horizon.