Here are the top eight lessons that I feel all entrepreneurs, especially in the technology space, should heed. These are particularly applicable to software, specifically B2B software, and the service space.

• Your superb start-up "idea", or your "IP", is not enough.
  The real crux of building a business is just that - building the business. In building a successful business, relentless execution is far more important than a great idea or superior intellectual property. Many people dream of great ideas all the time, few really do anything with their idea. Chances are many people have already had the great idea, perhaps an even greater idea than yours. While protectable intellectual property (IP) is helpful, it is neither a necessary nor a sufficient condition for creating successful and valuable business. So don't get obsessed with your idea or your IP itself, rather focus on starting and building the business.
• You can't make a start-up happen by working at it part-time.
  Most entrepreneurs try to start their venture in a lower-risk manner by keeping their day job, or doing some consulting work on the side (which pays the bills), while they are building their new venture on the side. This usually doesn't work. When the venture needs it most, your focus and your energy get divided. The real action and progress in building a start-up happens when you make that "yet another" cold call, looking for your first customer, on that dull Friday afternoon, when otherwise you would have been working on your day-job or your bills-paying-consulting-gig.
• Don't confuse product based and service based business models.
  A product based business requires upfront investment in building the product and building a sales & marketing organization that can sell that product. On the other hand, a service based business requires selling and delivering core capabilities. The two require very different business models. Often you can start with a services business model (offering consulting services to your target market) and then over time, productize your offerings to build a software product. This evolution works quite well and there are plenty of successful software product companies who can trace their start-up roots back to a services business model. But the important thing is to build the product in roughly the same market space or domain in which you are delivering your services. What doesn't work is when you start out as a services company and then try to add software products that are in a completely different market segment.
• Remember, nothing happens, until sales happen.
  While you can get lucky and land one (the first) customer or even a few customers without following a real sales process, you really can't build a business without a systematic approach to selling. While selling is not rocket science, most of us need to learn how to sell. Although effective sales techniques may differ from business to business, what is common across the board is that a sales process needs to be highly organized and metrics driven. Don't go for indirect sales channels too early in your cycle. In any startup, the most effective sales people are the founding partners (regardless of their official title), because they have the conviction and the passion for what they are offering. Early in the life of a start-up, using indirect sales channels are not only almost impossible, but also detrimental. It is the direct contact with real customers that provides real market feedback to the founders to help evolve the business idea so it can be successful. Using indirect channels too early chokes off that market feedback for the founders. Indirect sales channels and partnerships are much more effective later in the life of a startup, when they have established their product/service, have successful track record of a number of happy customers, and hopefully they have built a (brand) name recognition for themselves. At that stage an indirect sales channel can be used.
• Co-founder partnership based on trust, fairness, professionalism, and above all, (financial) transparency.
  Building a technology business as a sole founder is usually difficult. There are too many different skills required that are unlikely to be found in one founder. So it is natural to have two or three co-founders, with complementary skills, who get together to form the company. While skills of each co-founder are important to keep in mind when forming the partnership, what is far more important is that you are on the same page with your shared vision and values. Enter into the partnership with mutual trust, professionalism, and complete transparency. To avoid future heartburn and misunderstanding, it is a good hygiene to put your partnership understanding in writing.
• As far as possible, avoid external capital.
  Some startup business ideas are such that you have to raise capital to get off the ground, but many are not. If you can avoid raising money, do so. As soon as you take someone else's (friend, family, angel, or VC) money, you now need to live up to a higher standard of fiduciary responsibility and performance. It is natural that the investor will need some visibility and want to have a say in how the decisions are being made. This can be quite distracting and constraining to a startup. If you can, strive to fund your company with revenues. You will spend more time looking for paying customers and less time creating PowerPoint decks and business plans for potential investors. In the early stages, talking to customers is a much better use of your time, since each meeting provides real market input. Landing a paying customer is a great validation of your business idea and vice-versa. Furthermore, a tight cash situation brings in great financial discipline to the start-up, helping achieve operating profitability for the start-up. Of course, when you don't take external capital, you also don't end up diluting your own ownership stake in your venture.
• Branding 101 - make your name easy to be remembered and found.
  Pick a one-word name for your company and put all marketing focus on building that brand name. Avoid situations, for example: the company's actual name is Exigent Global Systems Inc, but it is sometimes known by Exigent, sometimes by EGSI, sometime by Exigent Global, and their website is www.exigent-global-inc.com. Strive to come up with a name that is indicative of your business and also ensure that the exact same URL is available to you for your company website.
• Build software using Agile approach.
  In the last two decades or so, the software development industry has really matured a lot. The earlier approaches to building software were borrowed from other engineering disciplines like manufacturing, building and construction. While these development approaches seemed logical - first gathering complete user requirements, then going through a thoughtful design phase, then building software, then testing it, and then handing it over to the customer - they were deeply flawed for software development. Over the last decade, the industry has uncovered a much more appropriate way to build high quality software utilizing the Agile method. This method is more likely to meet customer needs. With this software development approach, the user requirements actually evolve and in response the technology and design also evolve. Agile is where you deliver working software in short cycles of 2-3 weeks each, with frequent testing and feedback from the customer.

- Hemant Elhence is the Founder and CEO of Synerzip. For the last ten years, Hemant has been involved with multiple technology start-ups, as a co-founder and as a mentor.

How software is developed has dramatically changed in last two decades. Now, software development has become a lot more predictable science, than the craft it once used to be. An approach to software development, known as Agile, actually embodies two decades of that learning. Most companies which build software will be well served if they follow the Agile approach to software development.

Less like a Craft, a Lot More like Engineering

Two decades ago, most software was largely written from scratch, with very little dependence on third-party, re-usable, building blocks. Developers had all the flexibility, as well as all the responsibility, for writing good code. For individual developers, the process used to be a lot more fun, but also lot more complex. That's when seasoned managers believed a great software developer is forty times more productive than an average developer!

But now, with the advent of various prefabricated layers of software and available building blocks, such as application servers, databases, etc., developers are relieved of many software housekeeping tasks. A developer's work environment is now significantly more productive with tools such as interactive development environment, automatic code checkers, etc. All of these available tools free developers from tedious, low-value tasks and their focus can be directed to writing code for the business solutions they want to address.

While earlier there was little upfront focus on developing test cases, software testing is now a mature discipline. Building test cases and rigorously testing software is the only way to ensure software quality. Good software teams routinely follow excellent practices like Test Driven Development. Before writing a single line of code they first write the test case to test their code. What a sound idea - development with an end in mind! This practice ensures that developers actually understand the real intent of the software requirements before cranking out code.

The above examples illustrate how the software development process has matured in the last two decades. As a result, building great software has become much less of a craft and lot more of a real engineering project.

The Remaining Challenges

While software development really has become a more manageable engineering discipline, it is not quite like manufacturing. There is inherent uncertainty involved in writing software. Research and design are innate components of "writing" software, and are in-grained in the process. Often a software developer will employ a trial and error approach to write a piece of software that actually performs as specified. Therefore, writing software is not as predictable as the manufacturing process is, and a different approach to managing software projects is required.

Another chronic issue with software development has been that of the "moving target" of requirements specification. The idea of casting requirements in stone and holding them constant, until the development team delivers, is actually a mirage. In fact, it is largely a flawed expectation. As Edward V. Bernard says, "Walking on water and developing software from a specification are easy, if both are frozen."

Agile Software Development

Agile is an umbrella term that encompasses different variations - Extreme, Scrum, Spiral, etc., some of which have been around for a while. But, recent thinking has expanded the definition of Agile further. The Agile approach essentially delivers a sound prescription for the ongoing challenges of software development.

The Agile process recognizes and embraces the reality that software requirements cannot be, and in most cases should not be, cast in stone at the outset. Requirements specifications must be allowed to emerge and evolve organically. Once this flexibility is allowed, the end result is a better product which is more whole heartedly adopted by the intended users.

Yet, as previously mentioned, the software development process requires a high degree of engineering discipline. The Agile development process prescribes a healthy balance between HOW you build software (i.e. the engineering discipline) and flexibility of WHAT you build (i.e. the actual feature/function specification, which always appears to be a moving target). Moreover, the Agile process allows and encourages different development teams to strike a balance that is most appropriate for their particular situation. For example, an early-stage start-up company building a new, innovative product needs lighter discipline and much higher flexibility. A mature software product company with an installed-base of thousands of customers may need much higher discipline and limited flexibility. Yet both teams can effectively implement the Agile process of software development.

Finally, the agile process serves software teams which are dispersed - with developers working from home, or in different office locations throughout the country, and around the world. In fact, the Agile process works very well with offshore teams, allowing companies to achieve the holy grail of software development: lower costs, higher quality, and better products!

- Hemant Elhence is the Founder and CEO of Synerzip, a Dallas based software services company. Synerzip serves small/mid-sized companies with dual-shore (US + India) Agile software development and QA/testing services. As a seasoned team of software professionals, Synerzip assists its clients in effectively leveraging the offshore advantage, without the upfront risk, hassle factor, and set-up costs.
Contact: hemant@synerzip.com