Clutch spoke with Dave Todaro, founder and president of Ascendle, about the software development process and keys to success in the market.
Please describe your company and your role there.
Ascendle focuses on delivering business results for visionaries through custom software applications.
If you have a new startup idea but no ability to execute, you need a team which can take that idea, distill it down into a useful software application (whether it be a mobile or web app), and then utilize our software development team to get that product built. We get commercial software products out to customers as quickly as possible, typically in a minimum viable product (MVP) form. From there, we continue to support and enhance the software, as customers provide feedback and direction, with production cycles averaging about two weeks. As part of each cycle, we collaborate with our clients, share feedback, and make sure our production is headed in the right direction.
I’m the founder, president, and COO of the company.
Who are your clients?
Our clients might have 30 software developers on payroll, but all of them could be busy with other products the company built and has been selling for the last few years. Or, if none of their developers are mobile developers, a mobile project would just turn into a distraction for the team. That’s when they can call Ascendle. We’ll help them flesh out the idea, prove its concept, and get the app built – whatever they need. The client can always build an in-house team later on, or let us keep cranking away at it.
We also work with startups that can’t afford the time effort and energy to learn how to build a high-performing software team quickly. Plus, once the first version of the app is built, most startups want to slow down development for a while and focus on making sales. We can quickly ramp up a team and then slow them down once Version 1.0 goes out the door.
So, the common theme of our clients would be: there’s a business visionary with an idea for a commercial software app – mobile, web, or both – but they don't have the resources, bandwidth, or technical expertise to get it to market quickly.
What led you to form Ascendle?
The genesis of Ascendle came from my now 30+ years of commercial software development experience. I learned first-hand how challenging it can be to build software and generate revenue from it effectively, especially in terms of spending as little time and money as possible but also efficiently evolving the product over time. I knew the key was in satisfying customers, but to do that we had to figure out first what their software really needed to do. They were the ones with the ideas, but our expertise was in figuring out how to turn those ideas into software – without inventing elements the customer didn't ask for.
Striking that balance led to the concept behind Ascendle, which I started four years ago. That concept was predicated on helping software professionals figure out how to do things better, and at the same time helping business leaders who were experiencing high degrees of frustration with software development and technical teams. It's very common to see non-technical business leaders pull their hair out over the fact that the development team can't tell them when it's going to be done, not to mention all the missed deadlines and substandard software. There are aspects of this within every company; business leaders feeling general levels of frustration at their lack of control (from their perspective) is a common theme.
So, my aim in creating Ascendle was to help business leaders get software executed in a predictable and controllable way. In many organizations, the business doesn't have a direct connection to the priorities of the development team, which then charges off and builds whatever it wants.
And our process is working. The biggest “complaint” we've heard from clients is that we could even work a bit slower. In the entire history of software development, I don’t think anyone has ever uttered the words "My software development team is going too fast!"
Creating Value in the Software Development Process
Once you have an idea, how do you bring it to market? What are the first steps you need to take in order to make it a reality?
The overall theme is to build as little as possible in order to prove a hypothesis. This sounds simple, but it's actually quite challenging. A typical business leader or entrepreneur will get an idea and immediately believe it’ll provide tremendous value. Everyone will want it; and not only that, they’ll want it in the exact form the entrepreneur first envisioned. Often – almost always, in fact – that initial software app idea is not what turns out to be successful. We need to acknowledge that the product is going to morph over time as we collect more data and more information. We actually won't know exactly what the product needs to do until people start using it (which is counterintuitive to most people; it's sort of a chicken-and-egg problem). But once people see and experience it, they provide the most important feedback, which is often contrary to what the visionary originally had in mind.
This would tie into Eric Ries' philosophy, as stated in The Lean Startup, which has its roots in lean manufacturing, Agile, Scrum, and whatnot. The concept is to build what we call a minimum viable product; namely, the smallest, simplest thing that could possibly provide some value to a portion of the target customer base. If we try to please everyone, we’ll spend way too much time. Instead, Ascendle will take the idea, crunch it down to its simplest possible piece, build it, get it into the hands of target customers, and then our clients hear what customers have to say. Even if they say it doesn't provide value at all, it’s helpful because then we can ask what would provide value to them. We take that feedback, use it to build the next version, and then we give it to them again. And we keep repeating the cycle.
What would you say is the core concept of your process?
The core concept of our process starts with working as fast as we can to get products into the hands of end-users. We use several techniques to get an idea of what we need before we actually develop any software, like building visual prototypes that people can interact with. There’s a trap in that, though: when people play around with a prototype that doesn't actually do anything, it's not actually working, and they can't be expected to buy it. It can bring us to a certain point, but not all the way. We still need to build a product that our client can ask people to pay for. Once this happens (even if the price is as low as a dollar), the perspective changes quite a bit; we’ve passed the mental threshold around value.
What you don't want to do is spend a year and many hundreds of thousands of dollars on a development team, only to find out that the software is something that no one wants. So, we figure out how to build something tiny, iterate, and be ready to pivot within 1-3 months. You may find that what you thought was the problem wasn't in fact the problem, but there's a new problem that can be addressed. There are many examples of companies that started out thinking they were going to build X that would work in a certain way, but the outcome turned into something completely different just because of user feedback.
Getting to Market Quickly and Selling the Minimum Viable Product
Modern platforms, instead of pushing out fixed products, are interactive, scaling solutions. Do you have any insights into how businesses can convince consumers to use their software in the first place, if they're not going to get value from it from the start?
The big concept is in the initial hypothesis. We need to start with at least something. As a business visionary, I can see there’s a problem in the marketplace, and I believe that there's value in solving it, so I'm going to talk to some people to see if they're reinforcing my views. That early feedback could suggest that I might have a great, revolutionary idea; but at the end of the day, we can only go so far with market research and focus groups. We still need to build something, creating and executing on our hypothesis. The key is to execute on as little of it as possible in a way that provides value but still gets the information we need.
Can you give an example of that?
If we had been the first people to come up with the idea of Uber and were trying to build an MVP, the first thing to do would have been to pick one market, instead of going to every major city in the world. The initial app, when requesting a car, would have simply sent an email to someone sitting at a computer, who then picked up a phone and called a car to that location. That's a way to build something very small. In that example, the app would only capture the GPS coordinates and send the email. The rest of it would be handled by the “man behind the curtain;” it's basically fake, there's no system in place. We're just trying to figure out if people might want it.
What we wouldn't do would be to build the entire user and driver app versions, designing them to support 100,000 simultaneous drivers when we only have two drivers. We wouldn't be worrying about other markets either or about advertising spend. We're simply going to focus on the hypothesis of people using their phones to summon a car and paying one flat fee. If we're successful, we can continue to build the system out.
What about “Big Ideas”? Why not shoot for the moon?
Staying humble can be tricky because most people will assume that everyone would want to use their system. We know now that everyone wants to use Uber, but we didn't know that when the company first started. In fact, there are thousands upon thousands of great ideas which everyone should have wanted, but no one actually did. As much as a business visionary believes their idea is great and everyone will want it, they still need to actually prove it.
The idea can even seem counterintuitive. Consider a public messaging system where everyone can post up to 140 characters for people from all around the world to see. That would have seemed odd to initial investors. As it turned out, that particular visionary was correct, and we now know about Twitter’s huge success, but he still needed to prove something small at the start. For every superstar success story, there are hundreds of thousands where the idea didn't work out. Unfortunately, a big percentage of them were undertaken by large companies spending millions of dollars, only to find out that no one wanted their product. Even if they had the kernel of a good idea, it never grew into the success they initially envisioned. If they had started smaller, though, they might have pivoted and adjusted over time and found the right paths for those products to grow.
And this is especially true when the idea is the foundation of a new business. People need to make sure that users will want to spend their money on it; whether that’s directly by buying it, through advertisements, or in-app purchases doesn’t matter. Until you’ve proven that you can generate income with at least a small part of your idea, you want to keep your initial investment as low as possible.
How do you identify a minimum viable product?
Eris Ries would say that we should take what we think the MVP should be, then cut it in half, cut it in half again, and then again. That's what should be built. I've also heard something along the lines of "If you're not embarrassed by the MVP, then you've built too much.”
The initial product is supposed to be small and basic, to the point where you almost don't want to ship it, but that's actually what should be put out the door. You want to reach that moment when version 1.0 can be shipped as quickly as possible. After that is when you really need to focus on listening and discovering what the product needs to do.
The Secrets of Commercial Software Success
What are the best ways to focus your efforts and get your idea to the end-product stage?
We use the Scrum process. Part of it consists of showing working software to our clients every two weeks while we're doing the initial development. As we continue development, and even once we ship version 1.0, many things are going to change quickly. The client is getting whole new layers of insight as people actually use the software for its intended purpose.
How we handle that feedback is by meeting with our clients every two weeks and reprioritizing, based on what we've learned. Instead of casting a six-month development plan in stone and not being able to change it at all, our plans are extremely flexible. The current two-week chunk is the only one which is locked down. During that time, I can look at my prioritized list (what we call a product backlog) and discuss it with the client. If we identify a feature lower down the list that has suddenly become imperative, we can move it to the top without a problem.
All of our project management, as well as the entire approach, is built around the MVP concept and being agile in responding to changing business conditions. These conditions should be driven by initial users adopting the software. Our clients are often pleasantly surprised by this because in the past, they’ve always been made to feel bad about making changes. But now they can see how easy it is to completely reform their priority list every two weeks based on what their biggest customer (the one who could fund the next six months of the company with a successful sale) wants. And if that customer wants features other users could also benefit from, then we can leverage those features for other companies.
Growing products organically involves getting a foothold like that – a solution that someone can install on their phone from the app store, start using, and allow us to see what needs to be done next. That’s how we’ll eventually get to the end-product.
What are some of the pitfalls of commercial software development, and how can your clients avoid those obstacles?
One pitfall is going too far in the opposite direction: not building something well. It doesn’t matter if they’ve cut their MVP down to 1/8 of what they thought it was going to be; that 1/8 needs to be built right: functional and rock-solid. Slapping something together just to get it out the door will turn paying customers against you. They won’t feel motivated to provide the feedback you need to grow the product and determine what it really needs to do. The scope, as it relates to effort and time, should only be restricted in terms of an overall number of features, never on the level of quality.
Another potential pitfall, particularly as it pertains to business visionaries working with a development team, is not working with a team that follows a Scrum-like process. The client needs to have demonstrations of real, working, and shippable software every two weeks. When I say shippable, I mean that the level of quality has been driven to the point of being production-ready. All tests have been run, the software has been reviewed from a high level, and it’s been used by the team itself. This will give us an idea of exactly where the product stands as well as provide the client the ability to give feedback. If something doesn’t match their vision or make sense to them, we might want to make tweaks before the product reaches a paying customer's hands. It's a fine balancing act because we don't want to create a situation where we’re rewriting a product four times before real users even get to see it. But at the same time, we need to understand how it's coming together.
It's also nice for our client to try out software internally as well as show it to friends and family. Having them play around with it will provide a glimpse of what the product needs to do. Getting a few potential customers who are willing to work with you through those early stages can be a huge benefit too.
One of the most common pitfalls is when a business hires a development team, gives them a bunch of money, and the next time they see them, three months have passed. That's a recipe for disaster. When they do finally get together after three months, neither team will have a good idea of where they stand. If that happens, your development team is most likely not building software in an incremental and iterative Scrum fashion in the first place. Many development companies execute Scrum well, but there are many more that don't. Long waiting periods are a surefire sign that a developer isn't building in a Scrum-based fashion.
Business visionaries often don't know what they don't know, or how their words will translate into software. If the work is permitted to go on for three or even six months without producing results, that’s what leads to horror stories.
Looking Forward to Future Commercial Software Projects
What’s on the horizon for Ascendle?
The company has been growing roughly 100% year-over-year. As word gets out, we’re finding more and more business visionaries who need us. Our goal is to continue finding clients who are excited about software and have new product ideas, then acting as a resource for them and helping them navigate those waters. It's an unfortunate reality that many people with software product ideas resort to offshore companies and cheap development, spend a bunch of money, and don't receive what they wanted. Those companies are missing that critical strategic piece upfront.
Without specific experience in the process of taking a concept and producing a revenue-generating software product, most business visionaries will encounter big gaps between their own vision and what the programmers envision. Risk in software isn't with the software engineers themselves, but with everything that comes before they can get their hands on the project. It really is important to have that consulting piece before the programmers are cranked up. Not to belittle the process, but writing the code itself is actually the easiest part. Not integrating a development plan with the business vision and goals is a sure route to failure.
As more companies see that process – and what Ascendle can do for them – we expect our client base to continue growing rapidly over the next few years. We’re very excited to be working on these commercial software projects and to see all the successful new products we’re helping to place in the market.
Is there anything else that you'd like to mention?
We help business visionaries figure out what it is that they should build. Many of them aren't used to the MVP concept; whenever we start an engagement, the first four to six weeks consists of an evaluation phase, during which we focus on what the plan is. We talk about the vision, the original hypothesis, and create a prototype of what’s being described. Based on our many years of developing and shipping software, we provide feedback on what could be trimmed from the original big-picture vision to find a client’s MVP. Even if a client may not agree right away that cutting back is the right approach, we can still help them prioritize features and make sure we build the most important parts first. Some clients will change their mind along the way, maybe agreeing to ship the first 10 of the 50 features planned.
Clients with commercial software ideas need to ensure they're working with an experienced team who can help them execute a plan. They need a team that can give them a lot more flexibility in terms of how big the product needs to be, how fast it can be done, and what the order of development has to be. Ascendle does all that. In fact, delivering on those strategies is where Ascendle shines.