Developing An API Product ft. Anthony Molzahn

VO: Let's get geared up for startup success. Join Josh as he interviews knowledgeable guests from all corners of the entrepreneurial world and gets the answers to the questions you've been asking. Get ready to learn something new on this episode of From Idea To Done.

Josh: Hey everyone, welcome to a new episode. I'm here with our good friend Anthony from Project Phoenix.

VO: Good morning

Josh: Anthony. Thanks for coming on

Anthony: Or Good afternoon,

Josh: .

Anthony: What time is this going out?

Josh: It depends on what people are listening to it, I guess.

Anthony: Exactly. Well, good day.

Josh: Yes. Tell us a little bit about yourself, about your company.

Anthony: Yeah, so my name is Anthony Molzahn. I'm the CEO of Project Phoenix and our company software development company. We created an instant API, an instant API engine for software developers to build, test and publish apps, to skip the API development process and to basically write better code faster. And for those out there who are listening, they're like, What the heck is an API? An API is the application programming interface. And what it does basically is it allows apps on the internet to talk to each other safely. It allows databases to talk to the public internet and back again. And it allows when they were first introduced the ability for software developers to speed up development of apps by hundreds of hours per project safely. And there's a standard of the internet. And what we wanted to do was see if we could write code that writes code that writes these APIs automatically to skip the menial work so engineers can do more meaningful work instead. So that's what we're doing.

Josh: Cool. What's your background?

Anthony: I have an art degree. . Yeah. And a long time ago in a galaxy far away, I was also pursuing professional golf. So definitely two things you need for a software engineering company

Josh: Absolutely. Definitely a pivot there. And I can relate, I've got a graphic design degree myself, so that's weird's how worlds collide.

Anthony: Oh my gosh, yes. Yeah, I do use it for the pitch decks for sure.

Josh: Absolutely. . So I want to talk a little bit about product creation when it comes to software. So web, mobile applications. A lot of our audience here is trying to figure out should they write an app? How should they build it? What things to think about. So when we approach product creation here at Codelation, we use the formula of generate a bunch of ideas and assumptions, validate your ideas, assumptions against a target audience. Mm-hmm. Make sure you're solving a real problem and anyone know someone cares about.

Anthony: Mm-hmm. ,
what you're doing. You want to build an audience to bounce those ideas back off of you want to then build your product launch and iterate from there. Feature development. Talk a little bit about how you approached the problem for Project Phoenix.
Yeah, so let's start with understanding where the saving came up with now. We started by solving our own problem. We do custom software development. That's how we had served our company, generating revenue by building apps winning bids from competitors by being able to build better code faster with basically skipping up to a third of the entire engineering project because of that, the API development. So we wanted to understand is this just something that we are going to use that's unique to us to continue growing our services development revenue. We did about a half million last year. We have about eight or 900,000 in our pipeline this year. And we're sun setting that because we found out it's gonna be more advantageous to us to actually share with the whole software development industry this DevOps technology that allows them to do more meaningful work. And so we're switching to subscription based revenue stream in lieu of services.
It's time for us to help people who kind of on paper in a business looked like us. And that means that we had to start validating understanding who our customers would be. And when we did that, we looked to folks in our network, we talked to collation, What's your software stack look like? What's the problems that you face today? And identifying where our sweet so would be. And we identified that when software development companies and tech firms, people who have internal teams when they're building new apps, when they're starting a brand new project or they need to take an existing technology and then refurbish it, they've got the idea, the business process map as is. They need one that fits the model today, but they've already got the idea and they need new technology to rebuild it. That's what we found for our sweet spot. And so our approach was identifying who else would use our technology, who, what's the shape of that customer segment, how many are there? And what's the minimum amount of work that we need to do to put our instant API engine into their hands so that they can actually start sharing with us what else they need. And so that's actually where we are today as on our path to commercialization. Did that answer your question?

Josh: Yeah, absolutely. So your target customer would be companies like Codelation, other software development shops that want to speed up their development time, get more time back in so they can, like you said, build more meaningful features.

Anthony: Yeah cause then when we found out, turns out that the software development industry and all the tech firms, they need to hire as of today about a million and a half engineers. But there's only a 10th of that that's even available in the market to pick from. I'm sure you're like, when you're going through and you're hiring, you're like, Oh, could hire another engineer. Dang it. Cause that's the hardest one to find, right? The reason why it's there is because about half of all the businesses in the United States right now, they need that custom software developed. They need digital transformation. And if for those listening, it's moving from pens and paper and spreadsheets to a database and a platform that's built to serve the needs of the customers that these businesses are building apps for. And we found out about half of all businesses in the US, they have a budget for this, they have a budget, they're ready to spend the money, but they're just asking to get in line with other development companies.
I'm not sure what your buy looks like, but you're probably giving quotes out into like 20, 23, 24 . Right? That's a good problem to have. But it also it stymies the innovation for great ideas because this is not a throw more people at it problem. This is not throw more money. You have to approach, it says we need to create a behavioral change, we need to change how the process of software development is conducted entirely. And so that's where we started. So software development companies there's about 600,000 development companies, tech firms, and then about 4 million or so engineers in the United States. And so those are our three main groups at the end of the day. .

Josh: Cool. So you saw need in the market kind of what we term the use the term dog fooding, right? This is something that you're doing already. You found a pain point. How helpful do you think that was when you were validating that you were your own target customer?

Anthony: Oh yeah. Like our own customer persona? Yeah. Oh, persona. Yeah. What was cool here is that not only where we are our own customer we identify as one of the largest segments. Most software development companies actually are about our size between three and 10 engineers which was great because we needed to then understand how many apps would they be building for their clients each year. And we have made an identified an estimate of what, between six and 10 per year, depending on the size. Then you get the enterprise and that's a different beast entirely. But when we found that out, then we knew who is us, who has the process that's like us. So we can find our first customers, our innovators and early adopters, the ones who closely identify to us because they're the ones who are most likely gonna give us the feedback because there's such a great overlap. We'll just be having a conversation about things that we both enjoy in terms of team and development and business methodologies, because we do it the way each other does it. And I think that's more important, the relationship part. So yeah, I dunno if that answers the question, but I figured

Josh: Absolutely. So being an agency yourself, identify the problem, we've tried to pursue a couple products ourselves and the struggle is always billable time versus resources going out the door.

Anthony: Oh yeah.

Josh: Did you find any challenges with being able to put food on the table and also work on the product as well?

Anthony: Not at all. No. Not challenge. It's super easy. No. So what we actually ended up doing is we have created a, I don't know, an amalgamation, a business analysis process that takes the agile lean methodologies ways of non-waterfall based development, backed it all the way up and says, okay, if we're gonna help our customers building an app for them to help them solve their problems for their customers let's look at this not as a set of features that's gonna go into the app. Let's first start the outs at the a hundred thousand foot view a business analysis. What's the problem we're solving? What's the guardrails? What's in and outta scope? Why are we doing it? What's the business use case? And then map it out, a set of business process steps that actually identify from start to finish before you choose how you implement it.
It could be done with humans, it could be done with software automation, outsourcing, whatever it needs to get that business process. It looks like a, looks like a circuit, like a grid, a circuit grid. And in the end you could stick to that. And that's what we found is an opportunity for us to show our competency, what we are capable of in terms of understanding the organizational framework of an idea, and then putting that into a set of artifacts, deliverable documents, Here's what it looks like, here's what your process looks like. Here's what your big vision, We pull it outta your head, put it on paper, and here's how much we estimate that it would cost if we were to build it here. Take these documents, go shop around, go find a software development company that you feel is a good fit for moving your idea forward.
We would like it to be us. We'll use those as the framework, get those artifacts to move forward. And so to the point we took that first piece of the process and distinctly separated it from the actual custom software development, which is also agile billable materials. You only pay for what we actually worked for. And we worked on a retainer basis. It's a tough tool to swallow, especially if someone's staring at a $300,000 project and they're like, Well, we need $150,000 and the retainer to get started. Well, they know that long before we ask or send out an invoice, because the business analysis are just a few grand , We charged somewhere between 5,000 and $7,000 for a business analysis, depending on the size of it. And because we separated it out, it allowed our customers early on to get comfortable with knowing this is fixed, but this is how we operate. And then when they go into a software development with us, they're like, Oh, well it's just more of the same. But now we're actually doing the thing. We're actually building this. We've had an opportunity to identify and choose to move forward knowing all the variables ahead of time.

Josh: So you deployed your business analysis process on yourself?

Anthony: Yes.

Josh: Effectively.

Anthony: Yeah. In fact the two times we almost did not. And it's so funny because I'm sure anyone out there who in any space, you might have a process that you lean on that you use for your customers, and then you turn around and you don't use it for yourself. And we caught ourselves in the middle of like, Whoa, we forgot about our own scoping. We forgot about our own cpo, our own process. We have to do that stuff first. So needless to say, we are doing that. And I gotta say, it feels good because it's what we needed because we're at the time of this podcast, we're doing a round of fundraising, and this is what investors require, this is what our stakeholders require, this is what our customers require, what are you gonna do? When are you gonna get it done? And what's the benefit to me? And you have to write that down before you start.

Josh: Yeah. It's easiest as technologists just to jump in and do the thing that you're good at doing versus taking a step back and planning. You know, wouldn't dare put a pool in your backyard if you didn't have the designs and know where it's gonna go and how much it's gonna cost and all this stuff to it. But it's so easy just to jump in and start doing

Anthony: Not into the pool because it's not there yet. Of course.

Josh: Not there yet.

Anthony: Yeah. And of course then is it a sand vein? Am I building on an oasis to say, what does the actual foundation look like? Can I even put this here in the first place? It looks good, but can it support it? Right. No. Yeah.

Josh: So a lot of the people we work with are non-technical founders. I don't know if that's familiar to your guys' agency as well. Speak a little bit to them. If they're at this point in the process of trying to develop their product, there's lots of ways out there to get the software built. You can bring in a technical co-founder, you can ship this overseas to save some money, you can hire an agency, you can get an intern. How would you recommend that non-technical founder starts thinking about the actual development of their software?

Anthony: That's a great question. And it really comes down to gaining a better understanding of how the founder or the key decision makers, the product owner, really when it comes down to it as in terms of the software development who they are, what their competencies are, what they'd like to do. And that comes out in that business analysis, the shape of the things that they gravitate towards, and then understanding those gaps. Things that they need, perhaps it's personnel, perhaps it's contracting, perhaps is something that they can learn and do it and they wanna do it on their own. By the time we get to that point they'll know, Hey, we can be that tech team for you on the custom software development side, or we can help you find someone. We can help you find a software development company. If you do decide to hire we'd be working with them.
So you won't be alone . And it's really just guiding them through each decision and the impact of the choice that they make. And it is different each time. But if I were to give a piece of advice on a non-technical founder or co-founder someone who has an idea and requires software it starts with go to the end. What does it look like five years from now? If you want to do this in house, you're effectively asking and telling yourself and your team and your customers that you are a software development company. If you build it in house, you are a software development company. If that is not the answer that you want laid out for you in the next five years, then you outsource it and you contract for it, You find any way to have someone not on your team get it done. And that's okay , because there are great companies, I mean, there are people who are built specifically for that. I think a lot of correlations modeling, you know, build it, you hand it back to them, but then you're there to help them as changes to the software required to help their process. But they are not a software development company and they don't wanna be. So that's a good question.

Josh: And I, I've seen it too, where companies out raising funds and it's a really hard pill to swallow of like, Well, you found this great agency we would wanna work with. A lot of investors wanna say, you need to hire your own internal talent. And I think one of the things not a lot of people think about is we use the term appetite. What's your appetite to hire and train technology people? Do what languages you should be riding in? Do you have a business analyst on the team who's gonna manage the product? Who's your product owner? There's a lot of moving roles in there as well. What are some mistakes you've seen that people try to when they're trying to build their software that they may make? And I'll jump in with kind of one that I see a lot of is not understanding the product.
Oh, you talked about Agile. And so one of the roles in Agile that we use is the product owner. It's the person that's driving the direction for the business layer, , and helping the business analyst translate that into functional requirements so that the developers can pick it up and do their work. And I've seen a lot of people say, This is great, let's get going. And they don't realize how much work it is to be a product owner. And then the project spirals, it gets paused as they try to go find a product owner and thinking that they can just hire into something like this without the understanding of how much it's gonna take. So that's one thing we've seen a lot of. What things have you seen?

Anthony: Yeah, I kind of dovetail with that a little bit. One thing that we have noticed, and while we were doing custom software development, as we were building our company up to our point today these founders, they have these ideas, they're great ideas. And we get started with software development and we meet with them every single week. We says, Here's what we did last week, here's the blocking issues moving forward. Here are the decisions to make this week. Here's the progress, here's the new features. Test them . And you'd think that they would be right on it and testing it and giving you feedback right away because it's their baby. This is their invention, this is the thing that they are making sure it comes into existence. And then you're, oh, they didn't have time to do the testing. They didn't have time to, And I get it because they're busy doing a thousand other things.
There's the financial, there's the ip, there's the entity structure, there's the hiring, all of the other facets of the business. This is just one of them, . And it's the one that is actually driving all those other pieces. But because there is a relationship in understanding that someone else is, knows how to build it well, we trust you. Hold on. Agile requires communication. Agile requires that you have explicit signoff and fluid put on said a company who does not have a technical founder is gonna be completely reliant on both. Trying to understand what that process is as well as learning it and using it because they have to be part of that product owner process. That's a challenge. It's a good problem to have to get that far. But it, it's still a challenge. And I would say if you had to hire someone internally that it'd be someone who understands that they don't have to be an engineer. Someone that understands the agile process. especially from software. So

Josh: It's a lot of mental energy too, to plan the process. And I don't know how many times that you put a feature and a feature on a card. So we use Trello for our PM tools. We use Jira . Okay. Yeah. Same, same horse, different color. Yeah, exactly. We put our acceptance criteria, our breakdown, everything that's gonna happen. And there's still so much room for interpretation, no matter how detailed you can make that . And so just really understanding what are the business requirements, because if we leave a feature that we're gonna implement a search function, is it an auto complete search? Is it I type it in, I hit enter and it goes to a new page that that's where the thought process needs to come in. Or it's like, honestly, I don't care as long as I get search results back. Right?

Anthony: And that's something for us that being able to lean on that business process. It says, All right the business process step here is that we need to have results presented. And how that's done happens to be the search function the requirements of what the search results are gonna drive, the requirements of how this searching is done. Is it a dropdown list? Is it a radio buttons? Is check boxes, Is it a free form search? And what is the entities that it's searching against? The requirements will be driven by the output that is required for the customer, the step in that process that's gonna consume whatever that output is for us. We drive it from what was the requirement back into it. And that way we can stay, at least for us, that we can stay lean or agile in terms of only write it down what you absolutely need. And that comes down to assigning the task and building out the requirements in that task depending on who you assign it to. Engineer A has a different type of interpretation than engineer B. We have an engineer on our staff, but I can be like, do a thing and we write a task, no description. And he does it perfectly. I mean, another ones like, Well, you weren't clear enough. And it's like two paragraphs and that's okay. But we understand how we have to operate the human side of getting the business requirements finished

Josh: There. There's a video out there that we like to show to clients of a dad and his kids, and it's make a peanut butter sandwich

Anthony: . Oh dude, that's awesome. My kid is They actually had to teach the other kids in the class how to make a peanut butter sandwich. This is awesome. Keep going.

Josh: Yeah. We'll put it down to the link to the video and the show notes here. But it, it's teaching them how to understand in direction and instructions and requirements. And so it's spread some peanut butter on the bread. It's like, well, the peanut butter's not open, so they, He rolls the peanut butter jar on the bread.

Anthony: Oh yeah, a closed bag. A

Josh: Yeah, exactly. So it's like, holy smokes. There's so much stuff to think about. And I think that's where a lot of entrepreneurs get themselves in trouble of, I trust you. Just go build it. It's like if we go into a cave and build this thing, you're gonna waste all your money and realize this is not what you wanted.

Anthony: Dude. It's like whenever I go get a haircut I'll just head down to MJ Capelli and I'll just sit down in the chair and I often joke with them I'll close my eyes. I say, I'm gonna close my eyes and you just make me look the best version of what you think. But I'll pull out a picture, This is what my hair looked like last time. And I like it this way. Get close. I take off my glasses, I close my eyes and when I'm done, I get something that's close. So I've given them a scope of framework, what I, what's in and outta scope. And then I let them, at that point, I trust them with their process. And then the next time I'm coming for a haircut, I look for that person again, do the same thing. It's always easier the second time. And that's a term that you'll hear a lot in the technical world, .

Josh: Absolutely. You know, talked about getting your product up and going. You're in a fundraising mode. Yep. How do you recommend entrepreneurs look at, We use the term minimum viable product, . There's a term that we use as well. I can't remember who it's from but slc, simple, lovable, and complete. Oh, nice. Prototyping is another word out there. How far do you recommend startup take their concept of an mvp? And does that depend upon, are they raising money or what's the purpose of the mvp? Right?

Anthony: Yeah, yeah, yeah. Again, business requirements. So what is the minimum digestible product or service that you are providing to your customers? What are they willing to do to accept as a completed function to serve their business needs? What problem are you solving and how few features do you need to implement and enable in order to service their needs? So actually crazy. I did a guest lecture this morning at NDSU, North Dakota State University to a bunch of mechanical engineers, entrepreneur, and one of the questions that was asked was I've got this product and the big challenge we face, I'm like, We're 80 or 90% done, When can I start sharing it? I was like, Well, the short answer is you should have started sharing it when you were 60% done. That thing can be ugly as sin. You find one person that is willing to just take this thing, and if it helps them, then you can ask them all the questions. What would you do next? How does improve what wasn't useful? A lot of great ideas just wait way too long. The worst thing that can happen is that you engineer or build a product or a feature that actually doesn't serve anyone's needs. You've just wasted everyone's time. That's the worst thing that you can do. And so get it out there as early as possible. it like, Oh my God, you don't even really need an interface. Sometimes an MVP has shown a couple of mockups. Sometimes it requires a full IP, but not usually.

Josh: And I, I'd even push that further. I'd say 90% ago you should have been sharing it,

Anthony: Right? Well, yeah, yeah, yeah. Yes. To that point, yes. Yep. Exactly.

Josh: But yeah, it's so easy to go into a cave and develop something and then try to market it after the fact. This needs to see the light of air. You need your stakeholders, you need your customers. You need feedback on it. Cause for myself, when I've done that in the past and develop in a bubble, and then I show it to people and they're like, I don't really get it. You get defensive , like, How can you not get it? I've spent the last nine months of my life on this . Well, this doesn't make any sense to me. If you did it this way, it makes sense.

Anthony: Yeah. The bigger batch, you go into that process before you iterate and share and show new features, the harder it is to digest and take it. You get it too. I graduated with an art degree. How did I graduate with an art degree? Critiques. We didn't get A's and B's S. We got P and F pass fail. Basically, you get up, you showed your art, and it was either something they understood or you had to explain it until people understood, or you went back to the drawing board quite literally to try again to present your idea or whatever it was. And to further the point about the when should you show the product? What's the mvp? The second half of that is, have you, Why did you create this? Were you solving your own problem? In our case, it was. And so you can go a little further because worst case scenario, you have made your life better because you have done a technology or a product or service that makes your life the quality. Us just a little bit better and for those around you. And if other people buy on too, then now you have a business. And that's okay. Sometimes it's not the case and you'll have to validate earlier, but if you're solving your own problem, you can afford to go 50, 60% in

Josh: Yeah. And just to echo that, if you're not solving a problem that somebody on your team better know that industry really well, or you're gonna be in big trouble

Anthony: If you don't have a subject matter expert, an SME you need to find one. And I guess that goes all the way back to one of the first questions you asked here on this, up on the podcast is technical founder, non-technical founders, What do you need? How find a subject matter expert? Because either then they can tell you whether or not you need to bring someone on, or maybe they have the competency to be able to help fill in the gaps along the way. Find the subject matter expert for the output, not the technology that goes into it. Implementation is the second choice, not the first.

Josh: Yeah. The business layer drives the technology. I always joke, building this thing is the easy part. It's still really, really hard.

Anthony: Oh my god

Josh: But getting someone to understand what you're doing through a website that they've never talked to you to put a credit card on file to buy the thing. And then when that renewal comes to renew it because they found enough value in it. That's the difficult

Anthony: Thing, especially from subscription based stuff. , I mean, lots of studies are showing the average subscription is three years. People will buy into something that have absolutely, they are not used. I, I'm guilty that we all are . But to be able to go beyond that threshold that go to the fourth year, the fifth year, at that point, they probably have something to say about your technology too. , get them in a room with you, get 'em on a microphone. Let them share why they do what they do. Because then they're gonna help identify other people who are not just sitting around doing a passive subscription. You don't want passive clients. You want people who are using the thing. Help it propel the industry forward or whatever the product is. Right?

Josh: Yep. Yeah another thing that just popped into my head, I don't know how many people have said, Well, their software looks terrible. I can make it way better. It was like, who cares? Does it solve a problem? They can make their stuff pretty too. So if you're a me too product or agency, you're not unique enough and there's enough software out there in 2022 to choke a cow , you don't need more software that's not solving unique problem or unique angle to it.

Anthony: So yep. Mooove outta the way. It's funny to say that in our particular case I dunno if you've talked about on other podcasters, the Red Ocean, Blue, Blue Ocean Strategies, we're entering a market where we have effectively one direct competitor. They're an 800 pound gorilla, They've raised a 100 million series C, they've got a great go to market strategy, They've got a great product they do a good job, but they are the only ones really out there right now. And it's important to have competitors. And if you have someone that has come before either the first market and you can basically use their money on their terms to identify all of the mistakes that they have made and understand where your differentiators are. now a red and red. There's a lot of competitors and not a lot of differentiators. Now you have to look to the business later. What are those unique pieces? They're gonna come to you because you responded in 20 minutes rather than 20 days. Sometimes the product can be exactly the same, and that's okay. So if you wanna build a better go for it, just know what you're getting yourself into and how you're gonna differentiate is probably the humans more so than the product itself.

Josh: Yeah, no, that's a good point to make. And I think in your space of you've got one big competitor, but you've got apathy of like, Well, we're just gonna go build our own API and we don't need to deal with it.

Anthony: Oh gosh. Another one is the sum cost, which some cost fallacy if people follow that. We have talked to companies and tech firms who have spent 2, 3, 4, not months, years, building an api. Their product line is an api. Mm-hmm. , people buy companies because of the API they developed and it took years and to walk in and says, Well, now we have a technology that can do it 30 seconds. We have a technology that can do this in five seconds. And they're like, What you're basically asking 'em to do is be okay with the last five years of their life. And it's the biggest challenge that we're gonna face as we, Cause we're changing the behavior of how projects are developed. It didn't exist before , so don't feel bad it exists now. Do you wanna spend another five years doing another api? Are you sure? Yeah. So it's tough. And there are other partial competitors and there are other solutions. And of course the biggest competitor is not doing anything at all. . Okay.

Josh: Changing behavior is hard.

Anthony: It is having a few early adopters, people who can show why it was so awesome. People who know how to rally. That's really important. And I think one of the podcasts, one of the steps is give your allies, right? These are the people who are gonna show out the rooftops on your behalf. Yep. Because they can't help it. Sometimes it escapes lips and they're like, This is awesome. I mean, this is pretty cool. . Yeah,

Josh: Absolutely. Anthony, thank you so much for coming on today. Sure. How can our audience learn more about you?

Anthony: Super. That is a great question. So projectphoenix.io we are just getting started with commercialization. If you are a software developer or a software development company out there or a tech firm you understand a little bit about databases, a little bit about APIs love to have a conversation. Really just understanding how we can serve your needs on your next project. How our DevOps tool, how Devii DEVII, can actually help you move forward faster and basically make it so that your product sees the light and services the needs of the industry the way it should.

Josh: Awesome. Thanks

Anthony: Much obliged.

VO: Thanks so much for tuning in to this episode of From Idea to Done. If you're enjoying the show, please feel free to rate, subscribe, and leave a review wherever you listen to your podcasts. We really appreciate it and we'll catch you in the next episode.