The impact of Covid-19 was felt by Fortune 100 enterprises, including Hertz. The economic upheaval prompted the rental car leader to innovate. One innovation was to partner with Uber and Lyft, but the data needed was on a legacy mainframe system only accessible through a legacy API. This prompted Hertz to partner with Focused Labs to build a modern API to support their new business with Uber and Lyft.

The "Old" and the "New"

Since Hertz has over 100 years of history, it should come as no surprise that some of its technology has been around for a while and has aged. Even today, leaving the Hertz rental lot requires handing a slip of paper to a human. However, Hertz aspires to be a modern technology leader, with recent initiatives such as partnering with Uber and Lyft and introducing a fleet of 100,000 Teslas. However, their outdated technology poses challenges for their modern partners.

Partnering with Uber and Lyft revealed a three-decade technology gap for Hertz. Balancing their industry-leading "old" technology with the need to stay competitive with the "new" proved to be a challenge. To bridge this gap, Hertz needed a technology partner who understands legacy systems and can guide them into the future. They required experts who are familiar with both the "old" and the "new." This is where Focused Labs excels.

Hertz is like a 1972 Mustang Mach 1 that has been sitting in the garage for 20 years. It's an impressive machine that needs a modern tune-up to compete. Focused Labs serves as Hertz's supercharger, and to supercharge a classic, one needs to understand both the "old" and the "new."

Let's Take a Look Under the Hood

The integration of Hertz systems with the Uber and Lyft apps had a rough start. Existing integrations were confusing, based on an outdated version of the OpenTravel Alliance (OTA) specification, and utilized complicated requests in XML. Even when there were errors, requests returned "Success." Error messages were unhelpful, and warnings made no sense. This resulted in a confusing system, referred to as the "Legacy API." Uber and Lyft recognized that this was not sustainable, as bad integrations had burned them before. A better, modern, and self-describing solution was needed.

Designing a new API required a deep understanding of the Hertz domain. Uncovering this domain was akin to driving in the dark, and it was clear that a long road lay ahead.

Peering Under the Hood of Legacy Systems

Delving into legacy enterprise technology can be daunting. However, a thorough understanding of the legacy systems led us to design a better API. Knowledge of the inner workings and limitations allowed us to push the boundaries and breathe new life into this "classic."

We embarked on a journey of discovery by learning more about how the Legacy API works. Despite sparse documentation, we followed up with the team that maintains it. While this team lacked the domain knowledge we needed, we discovered that the Legacy API primarily converts data from another legacy system, which we'll refer to as the "Legacy Legacy API."

The Legacy Legacy API consists of on-prem, IBM AS/400 mainframes running COBOL. These mainframes serve the COBOL copybook format that is mapped to XML by the Legacy API. Since the Legacy API team mainly serves as a converter, we needed to collaborate with the mainframe team to understand the underlying data.

The mainframe team that owns the Legacy Legacy API possesses extensive business and domain knowledge. Collaborating with this team was the key to unlocking insights about the domain. Together, we were able to debug requests, decipher error messages, and comprehend the source of the data. Establishing continuous feedback with the mainframe team allowed us to iteratively discover, explore, and refine our understanding of the domain.

Embracing the "New" Hertz

As we delved deeper into domain and technical knowledge, we collaborated closely with Uber and Lyft to revamp the Hertz API. Our focus was on simplicity, well-documented contracts, and helpful error messages. Through iterative design, we aimed for a reasonable, descriptive, and pragmatic API. This involved working closely with our partners to address the limitations of the Hertz legacy system and finding creative solutions. For instance, scaling the mainframes that powered the Legacy API proved to be a daunting task. To meet the demands of Uber and Lyft, we had to come up with innovative approaches such as request limiting, caching, and algorithms to avoid unnecessary requests. The feedback from developers helped us ensure that we were building the right solution for our users. Leaning into Hertz Legacy and using insights to build a new API restored relationships with Uber and Lyft.

Hertz is now miles ahead of its Legacy API, with the new API continuing to mature. As of the time of writing, it serves more than one million requests daily, resulting in tens of thousands of rentals and generating over one hundred million dollars in revenue annually. Moreover, Hertz has regained its image as a reliable partner for Uber and Lyft. These remarkable achievements have laid a solid foundation for future product development at Hertz and marked a promising new beginning for the Hertz rideshare technology organization.

Where to?

The engagement between Focused Labs and Hertz exemplifies the principle of "meeting clients where they are." Hertz seized the opportunity to collaborate with modern technology companies and pushed the boundaries of their legacy systems. Now, rideshare drivers can effortlessly rent a Hertz vehicle through their app, and Hertz has unlocked a new revenue stream, generating over one hundred million dollars per year. This significant milestone for Hertz fills us with pride for being part of this journey.

What’s Next

If you have a legacy AP that needs refreshing or a legacy system that needs a modern API complete our Contact Us form, to discuss how the experts at Focused Labs can help.

Guiding An agile Transformation for Aperture’s Development Team

Background & Scope

Aperture Health wanted to work smarter — an agile transformation in product and software development was the direction they wanted to pursue. When a few software development contractors decided not to renew their work before finishing a project for Aperture’s client, Troy Anderson, chief production and information officer, saw an opportunity to partner with Focused Labs. He wanted to both finish a project in a time crunch and extend the working relationships to guide his team toward a more agile way of developing software.

Aperture Health delivers provider management software for companies all across the healthcare space. Anderson’s goal in working with Focused Labs was to enhance his team’s ability to build and deploy complex, specific and impressive software to their clients.

Focused on Delivery: Focused Labs developers accelerated product delivery for one of Aperture’s largest clients, while building a primary source verification (PSV) API to enable verification and credentialing. During these projects, Focused Labs enabled Aperture’s team with the benefits of Extreme Programming.

Focused on Results: Quickly saved a time-sensitive project abandoned by previous development contractors. The PSV API made verification possible within hours instead of weeks. Aperture’s engineers have embraced more pair programming work and significantly improved the daily working relationships between Aperture and client stakeholders.

Focused on Partnership: Aperture partnered with Focused Labs to imbue agile work states within their engineering teams while also quickly building software for a client. This will give Aperture a more agile approach to building and deploying valuable software going forward.

Guiding an agile transformation 

Aperture Health wanted to work smarter — an agile transformation in product and software development was the direction they wanted to pursue. When a few software development contractors decided not to renew their work before finishing a project for Aperture’s client, Troy Anderson, chief production and information officer, saw an opportunity to partner with Focused Labs. He wanted to both finish a project in a time crunch and extend the working relationships to guide his team toward a more agile way of developing software.

Aperture Health delivers provider management software for companies all across the healthcare space. Anderson’s goal in working with Focused Labs was to enhance his team’s ability to build and deploy complex, specific, and impressive software to their clients.

Building time-saving healthcare APIs ahead of schedule

The first development project between Aperture and Focused Labs started in December of 2020. The previous team of developers had ended their contract before finishing the job, so understanding the work and its context was the biggest issue in getting started.

The project needed to be finished quickly and Focused Labs was up for the challenge. “Having partners who can quickly staff up like Focused is nice to have,” says Will Reed, former head of engineering at Aperture. “They basically hopped onto a speeding train from a standstill.”

Aperture needed Focused Labs to help build out a primary source verification (PSV) API for a client. PSV is the method a healthcare provider uses to verify someone has the right certificate, license or registration to practice a profession. This important piece of Aperture client’s work was taking weeks to accomplish due to lack of automation in sharing that data.

Focused Labs quickly built a self-service API that enabled Aperture’s client to accomplish PSV within hours —not days. By automating the data retrieval process between accreditor and provider, this software cut PSV requests — which could manually take more than three days — down to four hours. They further streamlined the process by then developing automated billing and invoicing for the API clients.

And they delivered it all three weeks ahead of schedule.

Proving the benefits of an agile transformation through pair programming

During this project, Focused Labs’ developers worked alongside Apertures' to show the benefits of pair programming. Aperture wanted to move away from a waterfall-type workflow to more iterative development. Focused Labs showed Aperture’s team the benefits of things like weekly team rituals and a cadenced release schedule for a project in progress.

Focused Labs also collaborated with Aperture to bring more modern tooling into their work environment. When partnering with development teams, Focused Labs always looks to implement new modern systems. With Aperture, the legacy applications they were previously working with made it virtually impossible to find out when the software Aperture was providing to its clients was faltering. To close that feedback loop between Aperture’s clients and Aperture, Focused Labs suggested and then implemented new tooling — such as New Relic — to facilitate performance monitoring. This way the client did not need to alert developers when things were breaking — they now had the tools to monitor performance themselves.

Through working in a more collaborative, agile process, Aperture was able to solve problems in smaller chunks which led to a greater end result. Focused Labs also worked directly with Aperture’s client development team to mend the communication and relationship that had been strained by the contractors who left the project unfinished. This direct communication and collaboration has led to significant improvement in workflow and understanding between Aperture and their client stakeholders.

Making an agile transition away from top-down workflow

Aperture could have used any other development partner, but what was appealing about Focused Labs was the culture and workflow they were able to model with Aperture’s team.

"Focused Labs are educators and modelers of new behaviors and new practices.

Our team brought the knowledge of the tech stack and Focused Labs were bringing tools in terms of how to work and how to gain confidence about the software that is being built. Everyone’s adding value from day one,” says Reed. “Focused Labs are transferring their process to us and their job is to get out of here.”

Focused Labs embodied the best ways to produce valuable software for Aperture’s clients and worked alongside them to ensure they knew it was possible.

Product-Market Fit & Its Impact

Product-market fit is not just about having a good product; it’s about understanding the pain points of the target customer and bringing value in a user-centered and differentiated way. Without product-market fit, even the coolest product will not gain traction and adoption. 

The ways in which product-market fit has a significant impact on reducing risk and increasing confidence include:

1. Increases Customer Satisfaction: When you have a product that meets the needs and desires of your target audience, it becomes much easier to acquire and retain customers.
   
   
2. Increases Business Value: When your product generates more value, whether it's immediate revenue, rapid adoption, or organic growth, customers are willing to push your product to others, often leading to increased revenue and profit margins.
   
   
3. Reduces Time to Market & Cost: When you have a deep understanding of your target audience and their needs, you can focus on the features and functions that matter most to your customers and avoid wasting time on those that don’t.
   
   
4. Improves Brand Reputation: Customers whose problems are solved leave positive reviews and recommend your product to others, which can lead to more sales and improved brand awareness.
   
   
5. Enables Sustainable Growth: Products that meet a real need lead to long-term success for your business, which is essential for survival in today’s competitive landscape.
   
   

Just like start-ups, enterprises want to reduce the risk of sunk costs and increase confidence in the investments they make to develop and grow new products. However, enterprise product managers face different challenges in their pursuit of product-market fit. They need to answer to a larger number of stakeholders, have established customers with a higher baseline expectation of needs to be addressed immediately, and have more organizational overhead to manage when making any pivots in product direction. This makes every decision made more impactful, thus benefiting even more than startup product managers when they’ve effectively applied product market fit practices.

Product-Market Fit Applied

Product management requires a hybrid of functional and technical skills, balancing day-to-day activities with future planning. Product managers can achieve this balance by continuously monitoring four pillars of product-market fit: desirability, viability, feasibility, and strategic fit.

👫 Desirability (Think about the customer)

Become a problem solver by immersing yourself in the problems that customers face. Collaborate with designers to use User-Centered Design (UCD) practices to identify the problems that are worth solving. By identifying the most pressing problems and unmet needs of customers, you can design and build a solution that customers want to buy.

📊 Viability (Think about the business)

Drive value by understanding the desired business outcomes and determining if the target customer base is sufficient. Consider establishing key metrics to measure early and often in the experimentation and development process. This will help build confidence that the investment in development will yield the expected return.

🦾 Feasibility (Think about the solution)

Collaborate closely with design and engineering teams to determine the design and architecture of the product. Together, you can apply the "quality triangle" to balance the time, scope, and cost required to launch the product. This approach will help you deliver a product within the agreed-upon timeline while meeting user needs.

💎 Strategic Fit* (Think about the differentiation)

Enterprises often possess advantages due to their size, existing partnerships, and resources for scaling. To position your product to thrive, you must find the intersection of your company's unique positioning and the unmet needs of your target customer. This will also help define the necessary go-to-market strategies and priorities from both the business and technology sides to stay ahead of the competition. With initial market attraction and a path to scale, your team can build with confidence.

Case Study

During my last enterprise client project, I joined an existing product in development that lacked a clear view of its product-market fit. This becomes a major challenge because you don’t have a clear understanding of the priorities and why. As I had no historical context, it was difficult to discern which areas of the product were driving success and which were posing risks. However, it provided the perfect opportunity to assess the product by asking key questions related to each pillar of product-market fit.

I set up a space in Miro to conduct my product assessment and capture answers to questions around the product-market fit. I then conducted introductory conversations with customers of the product, stakeholders who interact with the product, designers, developers, and more so that I could have an inclusive and complete lens of the product's health.

To get started, you can use this Miro template to answer some key questions regarding each pillar:

After synthesizing the results of my research, it became clear what the top risk points were for the product. I was then able to prioritize the existing backlog and add new features that mitigated the risks, allowing new feature releases to drive immediate impact. This work increased the confidence of my team and surrounding leaders, alike, that this enterprise product was well on its way to achieving product-market fit.

Product-Market Fit Summary

In conclusion, achieving product-market fit is essential for the success of any product. It requires a deep understanding of the target customer's pain points and designing a solution that adds value in a user-centered and differentiated way. Product-market fit reduces risk, increases customer acquisition and retention, reduces time to market and cost, increases business value, improves brand reputation, and enables sustainable growth. Product managers can balance the competing priorities of their role by continuously monitoring the four pillars of product-market fit: desirability, viability, feasibility, and strategic fit. By applying these practices, enterprises can benefit from reduced risks and increased confidence, just like startups.

Learn How Focused Labs Can Help You Find the Right Product-Market Fit

If you would like to discuss your product-market fit challenges with the Focused Labs team, complete our Contact Us form, and we will set up a call with you and our experts.

The relationship between software product teams and business stakeholders is fundamentally broken in our industry. Business stakeholders seldom have the visibility they need to evaluate the productivity of their teams and those teams struggle to communicate it. Building software doesn’t have to live in a constant state of being over budget and out of time. Progress and timelines don’t have to be a mystery. I’ve spent the last 10 years as a software engineering consultant working with teams at small, medium, and large enterprise companies. It’s a prolific and acute problem. The simple practice of demoing working software is one of the most powerful ceremonies organizations can adopt to build trust and drive understanding. 

An emphasis on working software is not a new concept, it’s a core principle in the original agile manifesto: 

“Working software is the primary measure of progress.”

It’s the most important, and yet, it’s the first one to get buried behind all the other ceremony that has bloated “Agile software development”. When myself and Austin Vance started Focused Labs we wanted to ensure that all of our teams follow a practice of demoing working software at the end of each week. Shipping code is the ultimate goal. Demos are also the most powerful way to reshape the relationship between the business units that fund software and the teams that write software. It is the single most important ceremony for software product teams to hold themselves accountable to.

So why is demonstrating working software so hard, and why don’t we see it more often? Well, strong demo practice is the culmination of a highly functioning software product team. It requires that the product being built has direction, purpose, and a sense of priority. It requires planning ceremonies that are efficient with succinct backlogs. It requires that there is a concise and demonstrable definition of done. It means that developers have confidence in their code and introduce change with ease. In essence, it means that your agile process actually works. That’s not common in the software development industry. Demos are a forcing function to get there.

Let’s define “working software”

A common definition is important here. Many teams miss the “working” part of working software. Without adhering to this definition of working, demos devolve into just another status meeting.

Working software is:

• Functional: It provides a capability as is. It is something that could be provided to an end-user in production and they would get utility out of it. 
• Integrated: The software is not on some repository branch or fork of the product. The code is working alongside all the other code in the product.
• Available: The software product team doesn’t have special access to the software. Stakeholders and humans outside of the team can access each and every feature that a team demos.

Don’t confuse working software with finished software. The software does not have to be finished in order for it to be working or demonstrable.

Let’s look at a simple example. A team is building login functionality for a new application. The business knows that it wants:

1. Users to be able to create a new account based on their email address

2. Login with Social SSO (Google, Twitter, Facebook, Microsoft, etc…) 

Most teams would tackle the login feature described above as a single unit of work. It would not be considered finished or demonstrable until users could either create a new account with their email address or opt to login with one of the Social SSO options. Inevitably, the team realizes there is a 3rd point of complexity; 

3. Users who previously created an account via email should be able to merge a Social SSO login with their existing account.

Now, new scope has been introduced, estimation of effort is inaccurate, the feature is still not finished, and nothing has been demonstrated. Despite having just described three distinct states of working software, most teams would think about and demo it as one.

Teams that force themselves to demo working software regularly every week will need to tackle work in smaller, more discrete units.

1. Week 1, Demo 1: New users are able to create a new account and login via their email.
   
   
2. Week 2, Demo 2: New users are now able to optionally sign up via a Social SSO.
   
   
3. Week 3, Demo 3: Users who previously created an account with the email can opt to change their login to a Social SSO login.

A login feature that only allows users to sign up with their email address is working software even if the Social login option is never completed. By building and demonstrating the login feature in this way the team minimizes WIP (work in progress) and provides the option of abandoning #2 and/or #3 from above because the software is already in a working state. If we extrapolate this example and think more broadly about how software projects typically go, this is the crux of the problem. Teams try to build too much at once, unvalidated scope inevitably creeps in, and stakeholders are asked to bear through delays and setbacks. A promised “big reveal” rightfully leads to skepticism. Consistent and continuous momentum is a much easier foundation to build trust. Trust erodes when a team only communicates about progress in terms of burndown charts, high-level roadmaps, or stoplight-colored status reports. Progress needs to be measured by the amount of working software produced!

A strong and consistent demo practice will…

Create alignment and solicit feedback: There is immense power in showing iterative working software week after week. The standard response from stakeholders is a stronger sense of understanding and ownership. The team is consulting stakeholders rather than just informing them of status. They become a part of the conversation about what the team is doing, why they are doing it, and what they should be doing next. The business is able to provide concrete feedback rather than continuously asking when it will be done.

Demystify the software itself: To many clients I have worked with the software they are responsible for is a mystery. It’s easy to conjure up an inaccurate mental model of what the software is and what it does when it is not in front of you regularly. Early demo sessions tend to reveal a lot of surprises: “Oh, I didn’t realize that wasn’t an automated process” or “Wait, we don't track that data on a per-user basis already?”. By pulling the individuals responsible for budgeting and funding the software into the actual development process, they are better able to manage risk and are more informed about their investments.

Make the hard conversations easier: Demonstrating software changes every week reshapes the conversation when things go wrong. By keeping the feedback loop tight, going down the wrong path is kept to a minimum. When an integration turns out to be more challenging than initially anticipated or data that was presumed to exist actually doesn’t, it’s addressed earlier rather than later. Small mistakes don’t spiral into big ones, which is very taxing on the relationship and erodes trust.

Drive more agility into teams and process: As we saw in the example above, a team that demos every week must have small discrete stories that leave the software in a working state. This percolates into all aspects of the SDLC. Backlogs become more targeted, the definition of done becomes crisper, retrospectives have a more meaningful impact on improving process, and software gets shipped more frequently.

How To Get Started

At Focused Labs our teams follow these steps to establish a regular practice of demoing working software on a weekly basis: 

1. Schedule: The first step is to schedule them. Actually, put them on the calendar! We don’t wait until we are in a “good spot to start demos."
   
   
2. Lobby sponsors and stakeholders: Ensuring that all parties understand why demos are important is key to their consistent attendance and participation. We want stakeholders to be engaged and supportive of this practice. Havin them work with the team and celebrate wins goes a long way to making the practice stick.
   
   
3. Prepare: Demos take preparation. Having slides to frame the narrative and tell a continuous story is important. The Product Manager typically articulates this narrative and frames what the objective for the week was and how it went. A reminder of the elevator pitch for the product every week is strongly encouraged. 
   
   
4. Demo the working software: Put the slides down and the software up via screen share. Make sure that links and login access are readily available to your audience. Walk through completed changes for that week and talk about them in terms of what problems they solve for users and what value they bring to the business.
   
   
5. Take Questions, Ask for Feedback: Make sure you field questions, solicit feedback and address comments throughout.
   
   
6. Share What’s Coming Next: Make sure you talk about what the plan is for the following week and how learnings from this current week are playing into next steps.
   
   
7. Be Consistent: Do it every week and always find a way to demo working software even if the changes are minimal.

Go forth and demo working software! If you are interested in learning more about Focused Labs or our approach to delivering working software drop us a line!

Automating Core Business Functionality at Inner Matrix Systems

Highlights from Our Session with the CMO of Lettuce

In these videos, Jennifer Bell, CMO of Lettuce, and Austin Vance, CEO of Focused Labs, discuss how to foster long-term customer loyalty, build stronger customer relationships, and increase customer lifetime value (LTV) with an enhanced, modern mobile application designed to leverage AI and support data-driven marketing strategies. Hear the journey Lettuce undertook to evolve its reservation-only mobile app into a strategic data-gathering asset that delivers a better customer experience.

Considerations for Building Custom Apps and Experiences Instead of White Labeling

How to Supercharge Your Loyalty Program and Capture a New Market with a Digital Experience

How to Make a Leap of Faith Pay Off Without Too Much Risk

Secrets to Building the Best-Possible Modern User Experience for a Heritage, Multi-Brand Company

Learn How Focused Labs Can Help You Gain the Business Benefits from Developing a Custom Mobile App

If you would like to discuss your business needs for a custom mobile app with the Focused Labs team, complete our Contact Us form, and we will set up a call with you and our experts.