Watch Part 9 of our Accessible AI Talks, where we discuss how generative AI is transforming software development in 2024. In our last episode, Brian Woodring and I gave you an inside look at Phoenix Burst. Now we’re joined alongside two special guests, John Comiskey and Lindsay Bennett. John, instrumental in Burst’s technical innovations, and Lindsay, an expert product leader and requirements engineer, will put our latest generative AI tech to the test in what we call the “Lindsay Bennett test”. We’ll see if Phoenix Burst’s AI-generated requirements can match or exceed Lindsay’s standards.

What’s in it for you?
1️⃣ Understand how AI and generative AI are transforming traditional software development processes.
2️⃣ Explore real examples of how AI, specifically Phoenix Burst, is applied to create software requirements and artifacts from complex regulatory documents.
3️⃣ Watch Lindsay assess, drill down, and give real-time feedback of the requirements generated through Phoenix Burst.
4️⃣ Gain insights on the practical implications and overwhelming potential that exists by integrating AI into software development workflows.

AI is largely a ten percent job, ten percent of the time, for ten percent of your team. Mortgage business leaders continue to need to keep their focus on operations, compliance, and customer success. Technology leaders have their hands full maintaining a hybrid ecosystem of core heritage solutions and more modern point solutions. They must also keep up with the crushing pace of change, constant drumbeat of integration challenges, and the latest security threats.

We believe every company in the industry needs a practical approach to artificial intelligence that can be implemented quickly and safely. Much has been written about the lack of modern technology in mortgage, and we see the mass commercial availability of AI and generative AI as an opportunity to leapfrog this prevailing paradigm. We believe companies who seize the opportunities in AI will be the ones that gain a critical edge over everyone else. Enter practical mortgage AI from PhoenixTeam.

We partner with clients to define a three-horizon strategy for AI, and to identify and enable a use case-based approach that can be implemented now. Our AI services team works with clients on two parallel paths – the first is to define and document the enterprise AI strategy, the second is to identify a use case and prepare the organization to deliver it. With a little bit of focus, this can all be done in two to four weeks.

There is no shortage of use cases across mortgage that are great candidates for AI, and we provide a starter set of 36 for you to consider. Not all of these are great candidates for the immediate term, but thinking on a three-horizon strategy helps to mobilize our teams to both innovate now (safely!) and also be ready for what comes next. Share your thoughts with our team and let us know how we can help you empower your organization, drive internal efficiencies, and better serve your customers with a practical, actionable AI strategy.

In our last episode, Tela Mathias and Brian Woodring explored the early stages of launching a generative AI product. Now, we’re showing you the tech behind it and giving you an inside look at Phoenix Burst in action.

What you’ll learn:

1️⃣ The process of prototyping with generative AI – quick wins and key learnings.

2️⃣ How we tackled technical challenges like context creation and content curation.

3️⃣ A live demo of Phoenix Burst: See how we generate user stories, acceptance criteria, and more!

4️⃣ Insights from our journey: Hear from our team who went from zero AI experience to building this groundbreaking tool.

Don’t miss out on this inside look at the future of software development! Whether you’re in tech, AI, or just curious about the latest innovations, this episode is for you.

Written By Tela Gallagher Mathias , COO and Managing Partner, PhoenixTeam

I’ve been doing a lot of feedback sessions for Phoenix Burst (www.phoenixburst.ai), which is a passion product for me. To date, we’ve been really focused on moving left to right across the product development lifecycle – meaning from the “concept” end of “concept to cash”. We’ve wanted to really understand the limits of generative technology for analyzing, decomposing, and improving existing knowledge bases so that we could create the core artifacts of software development – requirements, user stories, acceptance criteria, test cases, and synthetic test data. Basically the “write requirements” and “test solution” part of Figure 1.

One of the prevailing feedback themes has been along the lines of:

“That’s nice and all, but what about when I need to make modifications to an existing system? So much of what we do is to improve or adapt systems we already have. When I look in my backlog, at least half the user stories have nothing to do with our goals, what are you doing about THAT?”

What a great question, and I am glad that so many of you have echoed that sentiment.  Having been in the software business for 25 years, I’ve thought a lot about this problem, and have seen this problem in action many times. I have delivered some very valuable software – call it an 11 on a scale of one to ten. I have also delivered some software that was kind of meh – maybe a six of ten. And then there’s all the bad ideas and semi-built software that never made it to market for whatever reason.

I’ve had two great pivots in my product management philosophy. The first was when I attended a course taught by Marty Cagan in New York after his first book was published. The next was attending a large-scale scrum (LeSS) class taught by Gene Gendel. Marty’s class completely altered my thinking about how a product team should be organized and what the role of the product manager was. It taught me the true definition of minimum viable product (MVP) and opened my eyes to hypothesis testing. Honestly, it made me very depressed. I had been thinking about it all wrong for so far too much of my career. It took me about six months to really digest what it meant to me and my industry.

Gene’s class taught me that many of our delivery problems in software are organizational in nature, and, therefore, very difficult to solve. It also forced me to really understand and be able to take apart the systems we use to create software products, and to uncover the levers we can pull to improve outcomes. Also, very depressing since I do not control the budget or budget decisions for any of my customers. That makes it hard, almost impossible in fact, to address the organizational problems.

So that was a tough couple of years, but I digress. In any event, I’ve concluded that there is no one size fits all. For me, my business, and my customers, it’s more important that I meet them where they are and apply the best approach that has the best chance of creating better outcomes. Sometimes these are small gains and sometimes these are huge gains, but I am less depressed about the situation than I used to be.

So, what do all my customers have in common? They have goals. They also have systems they want to retire, replace, modernize, or otherwise improve. So, they all generally have goals and systems. And they also all want the same thing – they want their goals to be met by their system. Simple enough. Figure 2 shows what customers want.

Unfortunately, it can be devilishly difficult to know if our systems are meeting our goals. And it is even harder to prove that the goal was met. Also, as we’ve covered before, it takes too long and it’s too expensive. Generally, the process doesn’t look like Figure 2, it looks more like Figure 3, with myriad twists and turns, onramps and offramps. It gets very murky trying to get from my goal to my system. I’ll call this the murky middle.

Generally, there is not a direct line from goal to system and system back to goal, it gets lost in the murky middle. We do not know how much of our system is valuable. We do not know which parts are valuable and which parts are not. We are unable to easily quantify the potential impact of a change. We do not know which thing in our backlog will be the most valuable if we prioritize it.

The murky middle is the messy part of software development, it’s where those artifacts we’ve figured out how to generate in Phoenix Burst come into play. That got me thinking – if everyone has goals, and everyone has systems, what if we generate the requirements from the existing systems, generate the value propositions from the goals, and then see if they match up? That would allow us to determine if our systems are meeting our goals. By extension, it might allow us to determine the value of a change, we could probably even use this process to look at our backlog and find the most valuable things in it. How cool would that be? Cooler than cool. THAT would be a giant leap forward in our goal to make making software not suck. Or at the very least, it would tell us if the software we made sucked.

So that’s our next experiment. I hope you’ll get in touch if any of this resonates, and I’ll let you know what we figure out.

Many of you who know me have heard me describe my mission – freeing the American people from the bondage of joyless mortgage technology. For many years, this has been my easy and immediate answer to the question of what I do and why I do it. There is entirely too little joy out there in the software world, and there are entirely too few days on the planet. I’ve had a lot of loss in life, as we all have, and as I age, it becomes that much more important to spend my days with people I love doing things I feel passionate about.

Much of the dominant mortgage technology out there is . . . of a much older vintage than the modern technology products that get so much attention from the product legends of our time. Servicing operators are among the most innovative users out there, simply because they have had to fashion a staggering number of workarounds required to serve customers and implement the mountain of compliance requirements inherent in the heavily regulated field of mortgage. The technology debt created by this fragile and complex ecosystem is felt most painfully by the operators, otherwise known as “The Business”.

I love my work. I love my clients, my teams, my partners. I love the problems I face every day with my customers. There is certainly no shortage of opportunity to fix things and make them better for users. That continues to be my focus. However, with the mass availability of generative artificial intelligence (genAI), I now also spend a small fraction of my time on my new passion project – putting joy and purpose back in software development with genAI based approaches.

As we’ve discussed before, this is both existential to my business and professionally fulfilling. I’ve had a lot of fun working with our small but mighty AI team on a product we are incubating at PhoenixTeam. Phoenix Burst started its life with a very practical problem: How can we rapidly plow through the massive body of regulatory requirements in mortgage, parse out the requirements, and automatically generate software requirements? Being in the mortgage technology business, this is a problem we face daily, across a diverse commercial and federal customer base. We have more than 100 people who tackle this challenge every day, so it seemed like a useful place to start. Enter Phoenix Burst.

A blue and purple sign with white textDescription automatically generated

 

We had many twists and turns along the way while testing our idea. None of our team members really had any experience developing around generative AI technologies, so we had a steep learning curve. We learned the fundamentals and managed to graduate from AI elementary school. We think we’ve stumbled onto something cool and, much more importantly, useful. We got some feedback along the way, although not nearly as much as we need, so we are planning to roll out the concept within the company. We have a captive audience of Phoenicians who need help, and we hope to get massive amounts of feedback and ideas from them.

One of the great things about what we are doing with genAI is that if we get it right, it will certainly work in mortgage for our persevering servicing operators, but our hypothesis is that it will also work in any domain space where people are trying to cut time to value in software development. And let’s face it, that’s pretty much every domain space. We are hoping to empower product development teams everywhere to make more valuable software faster.

A white outline of a personDescription automatically generated

So, what is next for us? We are thrilled to showcase the development version of Phoenix Burst at the Mortgage Industry Standards Maintenance Organization (MISMO) AI Summit in San Francisco this coming Monday, June 3, 2024. Not only are we “bursting” with excitement to demo our MVP, but we are more excited for the feedback and ideas Burst will invite. From there, we will roll out a beta product to a small internal user group followed by a generally available (GA) release to all of PhoenixTeam, and our early adopter launch later this year. I hope to see you at the Summit, in person or virtually. Come find me, I will have stickers and post-it notes for you!

Tune in for another episode of our Accessible AI Talks series, where we explore the power of AI in software development. In part 6, Tela Mathias, Chief Value Engineer and Managing Partner, is joined by tech visionary Brian Woodring for an in-depth discussion on solution design.

In this episode, we:

🔍 Explore the critical role of solution architecture in delivering scalable, high-quality software.

🤔 Analyze the current capabilities and limitations of generative AI in architecture design.

💡 Share real-world experiments and insights on how AI can revolutionize the architecture process.

Whether you’re a tech enthusiast, a software developer, or simply curious about the future of AI in the tech industry, this episode will be packed with valuable insights and practical takeaways. Make sure to hit that “attend” button or follow PhoenixTeam to stay updated! And make sure to tune in for our next talk where we’ll discuss gains across the software development lifecycle.

We’re excited to bring you Part 5 of our Accessible AI series, featuring our very own Teela Mathias and the brilliant Brian Woodring. This episode dives deep into the fascinating world of product design and how AI, especially generative AI, is poised to revolutionize the field.

In this episode, Tela and Brian explore the challenges and triumphs of integrating AI into product design. They share real-world experiments, like the fun yet insightful “peanut butter and jelly sandwich storyboard,” and discuss how AI can streamline design processes that traditionally take weeks, now accomplished in minutes.

Discover how AI can help create consistent personas, generate compelling storyboards, and even assist in high-fidelity design mockups. While the technology isn’t perfect yet, the potential is incredible, and we’re on the cusp of some game-changing advancements.

Tune in now to learn how AI can enhance your design process and keep your projects ahead of the curve!

#AccessibleAI #ProductDesign #GenerativeAI #TechInnovation #PhoenixTeam #FutureOfDesign

Value Engineer

By Tela Gallagher Mathias, Managing Partner and COO, PhoenixTeam

What is a value engineer?

In our Accessible AI Talks series with Brian Woodring, and in several of our recent articles, I’ve introduced the concept of the “value engineer”. We have seen some engagement around this idea, so I thought I would expand in this article.

It is really hard to make software. Too hard. At times, it is utterly thankless. Working tirelessly to bring a product to market only to have it miss the mark or miss the window. As one of my favorite clients reminds me so often – time is never our friend. Team environments can be brutal without the right people and the right leadership, and once trust is lost in a team it is very difficult to regain. I’ve said to my kids that trust is lost in buckets and earned in drops. The same goes for teams and the people on them. Lack of trust leads to a toxic team environment where we end up in teams of one – each person or pocket of people working for themselves. Psychological safety erodes. Internally motivated people start to retreat into themselves.

Throw in lack of a shared understanding of a shared vision, forget about it. Nothing valuable is getting shipped. And remember, that is an agile team’s single goal – to ship valuable software perceived as valuable by its users.

Now – it is not all bad out there. Despite my ostensible gloom and doom, I have the privilege of serving on some great teams – internal to Phoenix as well as my client teams. Teams that continuously adapt to change, that learn from the past and acknowledge it, that pivot when things are not working. These teams are doing great. However, it is no longer enough to learn from the past. It is now time to learn from the future because the future is happening now – right before our eyes – and it is squarely based on AI and generative AI.

The jobs in software development are changing. Somewhere between one and three years from now, we will see a rapid decline in the number of opportunities for product team members who have less than five years’ experience. And I’m talking about all the roles – from product owners to software engineers, and everything in between. Why? Because AI is eating everything, and AI-augmented software development is here. As Brian pointed out in one of our recent videos, there have been many advances in the developer automation space. Lots of copilot applications, and code generation is not as new as it seems. And that is all great. It is, however, predicated on having the right idea, the right value proposition, the right understanding, and the right language for the right audience.

Enter the value engineer. Value engineering is the process of removing all the waste and manual work in software development and letting generative AI handle that. The value engineer sits on the product development loop and curates results. He, she, or they are empowered with a new augmented product development platform that empowers them to create every artifact across the software development lifecycle with a single click (or maybe a few, but you get the idea).

(Em)powered by Phoenix Burst

We believe that a new role will emerge, one that pairs directly with the customer and the software engineer to rapidly deliver valuable product in about as much time as it takes today to achieve shared understanding (yes that can take a while but, again, you get the point). If we can understand a domain, and rapidly identify its special parts – the parts AI cannot find for us, the parts that come from decades of experience – we can create a product to enable it.

The value engineer is a modern-day superhero for modern-day product development. He, she, or they are a master product owner, a skilled test automation engineer, a powerful guerilla tester, a product designer, a software shipping solution architect – all rolled into one. And this role is emerging now. At PhoenixTeam, we are developing a product that will enable everyone to be a value engineer, and we are using it now. First it was a custom generative pre-trained transformer (GPT) to test our ideas. Now it is an (in development) AI-powered software development platform. At least that is what we hope it will be. We are still figuring it out. Join us for a preview at the MISMO AI summit in June in Las Vegas where we will show the first real version of our idea – Phoenix Burst.

Accessible AI Talks | The Problem of Requirements

Just dropped Part 4 of our Accessible AI Talks series. Tela and Brian continue the conversation and dive into the nitty-gritty of requirements in product development.

They’re breaking it down for you, sharing insights from their diverse backgrounds. Brian, with his software engineering expertise, sheds light on the misconception of over-specifying requirements. Let’s face it, we don’t need to micromanage button placements! Tackling the essentials is key to effective communication and shared vision among teams.

We’re envisioning a future where diverse artifacts combine to paint the full picture. From user stories to AI-generated insights, the possibilities are endless!

And be sure to join us next time as we tackle the problem of product design in our quest to make AI accessible for all.

Let us know what you think in the comments and thanks for tuning in!

AI Talks - Part 3 - The Problem of Shared Understanding

Part 3 of our Accessible AI Talks series is here, brought to you by Tela Gallagher Mathias and Brian Woodring. Today, we’re diving into how AI is reshaping software development and zooming in on shared understanding.

Ever been on a project where things slip through the cracks? We all know the struggle. Shared vision is key, as Brian said, “It doesn’t begin until you have a shared vision of success.”

But why is it difficult to achieve and maintain this shared understanding? It all boils down to a couple of things: every human interprets things differently and the dreaded time crunch.

AI is the game-changer here, ensuring seamless integration for all team members, anytime. Imagine a world where AI handles the grunt work, allowing us to focus on building rockin’ new products!

Let us know what you think and stay tuned for our next segment on how AI is revolutionizing requirements. We’re adapting with fresh approaches beyond physical proximity. Dream big, innovate bigger!