“We will never develop our own software; we are not a technology company!” I cannot count the number of times these words came out of my mouth during strategic discussions with my business partner.
Half a decade later, we have developed a proprietary platform for onboarding interim executives and recently released a technology platform directly connecting business leaders with business advisors. So what happened?
First, I have found that any time I stick to a single belief and use the word “never,” it ends up happening. Second, I have come to the realization that to serve the growing marketplace of independent executives and companies with whom we work, technology-driven solutions was our future. Given the infancy of the human cloud and gig economy at the time and the highly specialized nature of independent executives, we decided to build a custom solution. And so the journey began.
One of the best ways to learn how to do something is by doing it yourself. When it comes to software development, however, I don’t think this needs to be the case. If it were, then why are there so many popular books and articles on the subject, such as Traction, ReWork, and The Lean Startup?
A lot can be learned from others’ experiences. As a business owner and entrepreneur, here are a few of my lessons learned.
Lesson Learned #1: It’s Not for You
Our first technology solution had just about every bell, whistle, and feature needed to find an interim executive in a network of thousands. The problem was that we built it for ourselves, not the marketplace. Whereas we spend hours a day searching and reading through hundreds of resumes and profiles, the average business leader looking for an interim executive does not devote that much time to the search process. It would have taken a business leader as much time to learn to use all of the features we built as it would to find the expert they needed.
The Mistake: We were so excited about building software from scratch that we forgot to stay focused on who was going to use the technology and why. Anything was possible, but that didn’t make it necessary. We lost sight of why we were building our solution and for whom.
The Fix: First and foremost, remember what friction in the marketplace the technology is removing. Without clarity and focus on this, you may end up causing more friction than you solve.
Lesson Learned #2: Market Test
The saying in real estate is “location, location, location.” The equivalent in software development is “market test, market test, market test.”
This does not mean test until the product is perfect before launch.
- Test before anything has been developed.
- Start with an informal roundtable from your user base and get input.
- Continue to get input at each stage of the development process.
- Find a good graphics artist/designer for mock-ups use leverage them to get feedback before starting any costly development; it costs a lot less to develop a page of graphics than a page of code.
During the testing journey, beware of “that’s cool.” Just because you get feedback that a feature is “cool” doesn’t mean users will be willing to pay for it. Follow up with, “how much would you be willing to pay for that feature?”
The Mistake: The goal of each version is to market test each new feature before moving on to the next feature. Even though it is human nature to want to include everything, I would have benefited greatly to fight that instinct.
The Fix: My favorite quote is from Reid Hoffman: “If you’re not embarrassed by the first version of your product, you’ve launched too late.” Because you will likely end up rebuilding the product at least two times, the goal is to just get it out there and market test it. Plan each release with minimal additional features, starting with only those features that will solve users’ most immediate problem. (Note the word “problem” is singular; don’t try to solve more than one problem at a time.)
Lesson Learned #3: Business First, Technology Second
I learned after the initial release of our solution that finding the right technology partner—one who understands that the business and revenue model come first and the technology comes second—is critical. We didn’t need tech staff; we needed a technology partner.
The Mistake: My initial inclination was to find individuals who understood technology and would build what I told them to build, on time and within budget. But in the end, that ended up costing us both extra time and extra budget, because the first firm we worked with didn’t understand our business or revenue model, and giving us what we thought we wanted was not going to solve our business need.
The Fix: When interviewing staff or an outsourced firm, listen for questions that demonstrate they understand the business and revenue model. When I first sat down with our Solution 2.0 team, I outlined a number of iterations and future versions on a convoluted white board and asked, “What do you think?”
The firm owner asked me, “Which of these will immediately bring you revenue?” I circled the part that would most impact revenues.
His response: “Then we start there and focus there.”
Lesson Learned #4 – The Rule of 100
The Rule of 100: For every $1 you spend in planning, you will save $10 in development and $100 post-development.
I have found some of the best tools so far in our development journey have been Balsamiq or Invisionapp. When starting with nothing and needing to convey basic wireframes to a designer, Balsamiq is a good place to start. Once we had mock-ups and were ready to convey information to our developers, Invisionapp was one of the best finds.
The Mistake: Prior to using tools such as these, miscommunication, misunderstandings, and missing information caused wasted time during development.
The Fix: The goal is to storyboard the end product. What is the user story and what does it look like once coded? Invisionapp helps you do this. Once we started using it, we found all of the holes in our logic and user flow before starting development. The closer you can get to the finished product prior to development, the happier everyone will be with the timeline and product release.
Lesson Learned #5: Get Help
Bringing in additional IT expertise was one of the biggest turning points for us. We ended up putting a number of iterations on hold and focused the team’s efforts in a single area.
The Mistake: After developing our solution for a few years, everyone involved was too close to it. We brought in an outside IT consultant to step back and ask us questions.
The Fix: With no attachment to any part of what we were doing, an outside consultant was able to provide some much-needed clarity and focus. After identifying what would most affect our revenues, the consultant’s feedback was, “Let’s get this one thing right better than anyone else.”
Lessons can be costly and often unnecessary. When the opportunity arises to learn from someone else’s, take that opportunity every single time.
This guest post is courtesy of Kristen McAlister of Cerius Executives.