This difference in focus on results is what has always led me to prefer having in-house product development teams over hiring thirdparty companies to develop products. Third-party companies have the primary goal of selling more hours of software development. Consequently, they will always look for opportunities to sell more hours of software development. The monthly accountability report, which comes with the invoice we must pay, includes a breakdown of the number of hours worked by each allocated professional and a list of delivered features. While I have seen some demonstrations of delivering results for the company or the client in reports from software development outsourcing companies, this is quite rare.
Once, I had the opportunity to help a client make the decision to switch from an outsourced team to an internal team. Since the average monthly cost per person for the product development team tends to be similar, the switch would be justified simply by having the people on the internal team highly aligned with business objectives. In this client, one of the business metrics we tracked was the number of sales generated by this product development team.
It is interesting to note that while the team was partially outsourced, the number of new sales did not increase, even though it was clear that this was one of the team’s main objectives. Only after a few months with the team being predominantly composed of internal staff did the metric of new sales begin to grow.
I believe that by now, it should be quite clear what the main goal of any product development team is, but I’ll repeat it to make it even more explicit:
The number one priority of any team product development is to generate results as fast as possible.
Generate results for the company that owns the product and invests in building that product, and results for the customer, solving their problems and meeting their needs. It needs to happen as quickly as possible because generating results costs money, and the longer we take to generate results, the more money we spend.
I’ve mentioned some good tools to achieve results, and the third part of this book will be focused on this topic. However, we must not forget that they are tools to help us generate results as quickly as possible. Vision, strategy, team structure, OKRs, roadmap, proof of concept, MVP, discovery, prototype, website, app, functionality, bot, algorithm, and so on. The list is extensive, but we should never forget that all of these are tools to help us generate results for the business and the customer. Even the product, the word in the title of the product management function, is a tool to generate results.
To sell units in a new building, Lopes and the construction company establish a partnership in which the construction company shares information about prices, unit availability, and leads. Lopes, based on its extensive experience in real estate launches, works on selling these units.
To fulfill its duties in this partnership, Lopes needs information from the construction company about unit prices, which frequently change with sales evolution. They also need to know which units are available and receive leads from the construction company. Initially, this information was sent via files to be manually imported into their system. However, manual entry of information tends to be slow and error-prone, making it clear that this manual integration is not ideal.
The integration between Lopes and the construction companies also faced challenges. As a manual operation, it was performed once or twice a week, leading to outdated information on prices and available units in Lopes’ systems for its brokers to use. Moreover, the older the lead information, the colder it becomes, and potential clients likely find other ways to get the needed information, potentially closing deals with other vendors.
The problem was addressed with a focus on generating results as quickly as possible:
They opted for Solution 3 because it promised faster results. It took only a few weeks to have the first RPA working and delivering results. After a year using this solution, no APIs had been provided by the management system providers, and there was no need to build their own RPAs. The RPA provider worked well at a reasonable cost, allowing the team to focus on generating results from other opportunities.
A new team member at Lopes Labs, who came from an e-commerce website, mentioned that push notifications from the app at her previous workplace generated more leads and had higher conversion rates than SMS and email marketing. The team became interested in testing this hypothesis for result generation, but they didn’t have an app for customers to search for real estate, and there were no short-term plans to develop one.
The challenge was to test this hypothesis quickly and inexpensively. Building a native app with all the features of their existing site would take months, even with a significantly reduced scope. Even if they streamlined it to deliver some value to the user, it would still take many weeks.
Since their website was responsive, they devised a simple solution to test the hypothesis. They decided to create a webview app, a simpler solution than building a native app, even if they limited it to the minimum scope.
Interestingly, this approach is how Facebook and LinkedIn also launched their first mobile apps. Only when they realized the results generated by their apps and confirmed that a native version would bring even more results did they decide to invest in building their native apps. With this mobile app, they could confirm that push notifications generated more leads and had higher conversion rates than SMS and email marketing. They launched this app in early 2021.
It’s worth noting that these examples, including the app for brokers, the RPA, and the property search app, serve to illustrate not only the principle of “result delivery” but also the two previous principles of “rapid and frequent deliveries” and “focus on the problem.”
At the end of 2020, even with the Lopes Labs team focused on “result delivery,” “rapid and frequent deliveries,” and “problem focus,” they were still under significant pressure for feature deliveries. Despite being somewhat frustrating, I viewed this demand as expected since Lopes’ leadership was investing a considerable amount of money in Lopes Labs, with monthly costs growing steadily. This included expenses for personnel and infrastructure for development and hosting of applications.
Any company or individual making some form of investment has an expectation of a return on that investment. Lopes was no exception. The directors, board, and shareholders of Lopes expected a return on the investment they were making in Lopes Labs. This team was composed of product, design, engineering, and data professionals. What did this entire team do? The most obvious answer to this question is that they developed and delivered features, websites, apps, screens, algorithms, reports, etc. So, what should we expect and demand from this team as a return on the investment we made and continue to make? Features, websites, apps, screens, algorithms, reports, etc. Nothing more natural.
However, as seen earlier, none of these is the ultimate goal but a means to achieve objectives and results. Consequently, the Lopes Labs team proposed budgeting for 2021 based on three premises:
1. Stabilize costs: As mentioned, costs were growing month by month. The proposal was that costs would not increase throughout 2021, meaning any new cost would only come in with the removal or reduction of an existing cost.
2. Measure revenue: One of the expected outcomes of all this investment in digital product development is that these products generate more real estate sales. Thus, the proposal was to measure the amount of revenue generated from real estate sales originating from digital products.
3. Revenue > Cost: Lastly, the goal for 2021 was to have the revenue generated by digital products exceed the cost of Lopes Labs. And obviously, the sooner, the better!
This budget was approved, and that’s how they operated throughout 2021. At the end of the year, they managed to keep costs within the budget, and revenue exceeded expectations, eventually recording revenue greater than the monthly cost, demonstrating their ability to deliver results.
This article is another excerpt from my newest book “Digital transformation and product culture: How to put technology at the center of your company’s strategy“, which I will also make available here on the blog. So far, I have already published here:
I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.
Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its user’s problems, and achieve the company objectives? Check out my Digital Product Management books, where I share what I learned during my 30+ years of experience in creating and managing digital products: