Although there are many more pitfalls, I’m only going mention three. Feel free to add your own. The good news is that all of these risks are manageable.

Staff User Acceptance Testing Carefully
Startups are often based on the vision of a single person. As the old saying goes, vision is necessary but insufficient for creating success. It would be unusual for any one person to have all of the skills needed. Agile software development is great for optimizing product value and time to market, but it only works if the business stakeholders and user panels are participating in the various aspects of user acceptance testing on a timely basis. This includes participation in design reviews and demos, not just UAT. Agile relies on short feedback loops. You need both a visionary and a detail person on your team during the development process. Look at yourself critically. If you are not good at the details yourself, you need to hire or bring in a partner that is. That is the person that needs to be involved in the development process on a daily basis during design and development. It is probably also the best person to initially lead your customer service group immediately after launch. A visionary only needs to participate in periodic reviews to make sure things are on track.

Choose a Realistic MVP
Minimum viable product (MVP) is a catchy phrase, but it is often misunderstood. It means nothing without the context of a goal. It doesn’t necessarily mean a minimum or an incomplete product. First determine your goal – Is it to attract an investor? Is it to validate a target customer type? Is it to drive revenue? Then determine the minimum viable product that will achieve the goal chosen.

Most visionaries think that every feature needed for every possible customer type needs to be in their product at launch. The chance that all of the features envisioned can be cost justified rapidly approaches 0%. A study a few years back indicated that 50% of all features developed are never used to a measurable level. Start with the assumption that you know your initial feature set is probably wrong and don’t try to get the first release to satisfy all of your suspected targets. Develop your first release to satisfy the needs of your best customer target or a closely related subset of targets. Then start with the minimum feature set to drive value for that subset. This is part of customer validation. You will quickly learn if you are on track, which additional features you’ll need, or if you need to pivot and try a different approach (this is not necessarily bad – think of the pivot from The Point to Groupon).

Engage with Your Potential Customers Early – Don’t Wait for Launch
Often new entrepreneurs are hesitant to vet their ideas and conceptual prototypes with potential customers for fear of losing them as prospects. If your proposed product helps eliminate or reduce one of their pains, you’d be surprised how cooperative they will be in looking at your ideas and providing feedback. First, they are often flattered that they were asked, and secondly, over time they get the feeling that the product is being designed just for them. And, if they don’t see it as easing one of their pains, you may have the wrong product or the wrong customer target. That is good to know early on.

Take a hint from the major corporations. Most of them have some form of Voice of the Customer initiative. Their customers love to provide input, because it greatly increases the chance they’ll end up with a product that will benefit them. The earlier you get your targeted customer types involved in the process, the more likely they are to get a feeling of ownership and loyalty to your product. A better product and loyal potential customers – why would you not want to do this?

I could probably list another dozen, but now it’s your turn. What other pitfalls and mistakes do you see occurring over and over again?

Share/Bookmark

1. I need an application to get around constraints imposed by a vendor, whether it’s Microsoft, Apple (iPhone). – They’re going to find a way to block you or sue you before you recover your costs.

2. I want an application that combines the features of Facebook, MySpace and YouTube. – Only a few people have enough money to compete successfully and they know better. However, if you can create a niche (a specific subject or industry) and provide specific differentiators, there are possibilities.

3. I want a social media site to do “xx”, but I don’t have a revenue model. – Commercial quality custom software is relatively expensive. We like to work on products that win in the marketplace and have staying power. We’re willing to work with you to see if we can help you fill out your concept, but you’re not ready for development.

4. I need an application to let users design their own t-shirts, cards, etc. – there are already many applications available – too much competition. I get at least one request for this every month or so. The exception is if it is for a specific company that has a protected market.

5. I need a brochure site. – There are thousands of small firms that can do a good marketing web site at a much lower cost than us. We focus on sites and applications that require backend systems (databases, content management systems, etc.). We can refer you to a good firm for marketing sites.

6. I want to upgrade an existing VB6 application, in VB6 (rather than writing it from scratch in a more up-to-date language). – This would hold true for any obsolete technology. Chances are requirements are out of date anyway. You’re much better off starting from scratch with newer technologies. We’re more than happy to help with that.

7. I need help finishing up a site or application. It is 90-95% done. It just isn’t working right or doesn’t flow well. – My guess is it’s a long way from 90% complete and my guess is there are few, if any, automated tests. We see this a lot with people who have gone offshore to, in theory, save money. It is almost always more cost effective to start from scratch, though there is always some carryover value from a requirements and design perspective. If you understand this, and you have a viable concept, we certainly can help you create a great product.

Another variation of this: I have this green screen application. I don’t want to redo it, just make it look better. – i.e. I just need someone to put lipstick on my pig.

8. I have an application where user workflow and usability are not important. – It may be a good project for some companies, it’s just not in our sweet spot. We look for companies that want to use technology and user experience to create competitive advantage (which is why we do a lot with startups and new product areas for existing companies).

9. I need help with a php (or Python) application. – Again, good for some firms, just not our cup of tea. We’d rather use Rails, .Net or Java for these types of applications.

10. I don’t feel comfortable with the Agile development process. – Fortunately fewer and fewer people feel this way. Business stakeholders generally love Agile because it keeps them involved throughout the design and development process and they are focusing on the business value and in the best position to recognize needed changes. Only in very unusual circumstances would we agree to develop using a waterfall method. We’re more likely to listen to your concerns and figure out how to mitigate any risks you see. When I hear someone say they’ve had a bad experience with Agile, it’s generally because Agile best practices weren’t used.

I bet you have others – send them on and I’ll add them to my growing list. There were actually some much more exciting requests, but I was afraid to publish them.

Share/Bookmark

What are your legal concerns? 

If you are a startup or haven’t used an outside firm to develop software for you there are 3 basic documents you need to consider – a Mutual Non-Disclosure Agreement, A Master Services Agreement and a Statement of Work. This is from a business person’s view, not an attorney’s.

Mutual Non-Disclosure Agreement – the purpose of this document is to protect your idea, i.e. your Intellectual Property (IP). If you feel your idea is unique or if you will be discussing proprietary things during initial discussions, this should be executed before sending detailed requirements to the software firm. It should be mutual, because it is likely the software development firm has as much or more IP than you to protect and you want them to use that to your benefit.

You can find sample documents on the internet, just make sure the one you select has all of the standard exclusions, including reponsibilities in the event a court requires one of the parties disclose confidential information.

Master Services Agreement (MSA) – although small one time projects can be handled by a Statement of Work (SOW), for long or ongoing engagements you should have an MSA in place.

Generally, a MSA will include all of the standard legal terms related to the engagement, but none of the specifics of a particular project. This includes definition of who owns the code and IP from the engagements. This is extremely important. Make sure your attorney is involved, ideally one experienced with software development contracts. One way to tell is to look at the IP section. If it doesn’t reflect modern practices that involve incorporating Open Source or low cost proprietary modules into the code, you need to find more up-to-date wording. The software development firm cannot grant you IP for those modules since they aren’t the owners. They can make sure you have the proper “use” licenses and make sure they are implemented in a way that doesn’t jeopardize your IP for the custom portion of the code.

It is imperative that this be defined in the MSA, or in the SOW if no MSA is in place. Not all states handle code ownership the same in the event it isn’t specifically addressed in a contract. Sometimes it defaults to the client and sometimes it defaults to the developer. A firm I was talking with recently didn’t have this defined and the software company decided they should have ownership of the code.

The MSA should also address such things as: type of services to be performed, cooperation responsibilities, project management responsibilities, term, termination procedures, non-exclusivity, fees/payments, non-solicitation, publicity, jurisdiction and survivorship.

If it is likely that you will be working with the software firm on multiple engagements or if they will be involved in ongoing support of the resultant application, you should do the two step process of an MSA and SOW. There are two main reasons for. First, it covers any gaps for work done between or outside of existing SOWs. Secondly, it eliminates the need to include heavy legalese in each SOW. This speeds the approval process for subsequent SOWs and reduces legal review fees. In general, the less legalese in the SOW, the clearer it is for both sides.

Statement of Work (SOW) – The SOW should cover the specifics of the work to be done on a project – the features to be developed, the costs and the governance process at a minimum so that you know if you’re on track as the project progresses and you know when you’re done. It also should include any terms that are different that the standard terms in the MSA if one is in place. If there is no MSA in place, you need to add a more comprehensive Terms section.

Share/Bookmark

photo credit: TheNickster

Since Pathfinder Development focuses on software based product development I get 40-50 inquiries a month from people who are looking for design and development help. This ranges from people who just have an “idea” to people with detailed requirements and screen mockups. Though most applicable to startups, regardless of the stage there are a couple of things we look for first:

1. What problem is your application solving?
2. How does your product solve the problem?
3. Why and how will people beat a path to your door for your solution?
4. What are your market differentiators (and are they sustainable)?
5. What is the market size?
6. What is your revenue model – how will you get paid and how will revenue scale over time – this needs to be specific, even if a guess – how many users or licenses and what is your revenue per user or license.
7. What will it cost to design, build, operate (legal, accounting), support, market/sell – support should include both providing customer service and continually enhancing the product to keep it ahead of the competition.

Forget how cool you think the application is. Think about who’s going to buy it and what they are willing to pay.

Funding Expectations:

Although it can be less for a mobile application (iPhone, iPad, Android, etc.), for a desktop or software as a service (SaaS) application expect that your design and development costs for your first release will be in excess of $100,000 – probably in the $150,000-$350,000 area. Why? Think about it. If your application is so simple that it can be developed for $10-50k, how can you hope to have a sustainable competitive advantage. Your neighbor working out of his or her garage can look at what you’re doing and become your competitor. The more likely scenario is that a firm with more solid funding and marketing leverage will take your idea and keep you from achieving sufficient market penetration to be profitable.

Investing Wisely:

Rather that trying to spend $50,000 on developing an application, take a little more time to think through your idea, making it more compelling, and aligning marketing and operational resources that can help better define you product and its differentiators. If you think you have something unique and valuable, think of the minimum prototype you could build to validate your market and value proposition.

Most large cities have state and local organizations and incubators specifically organized to help entrepreneurs. Don’t feel that you have to go it alone, contact these organizations and leverage their services. They can help you vet and tune your idea into something that could be attractive to potential customers and to Angel investors or VCs.

Don’t let this information stop you from trying – it can be fun and rewarding, but it is much more fun if you have realistic expectations and can successfully bring your product to market. You win no points for half of a product or a product that no one will buy.

Share/Bookmark

By now almost everyone has figured out that traditional fixed bid doesn’t work for software development projects, especially where effective, intuitive user interaction is a significant component of success.  Over time there has been a lot of effort devoted to finding the underlying reasons for project failure.  The Standish Group Chaos Report for 2002 found that 45% of features developed were never used, their 2008 Chaos Report found that typical software projects come in at 189% of original estimates (there is an obvious correlation there), and many studies over the years have concluded that an uncomfortably small percentage of development projects are viewed as meeting or exceeding expectations or providing competitive advantage.

Hidden implications of “fixed bid”

Although you need to provide a target budget to get projects approved, “fixed bid” for application development starts of with a faulty basic assumption – that user, functional and system requirements are fully known and documented in a way that enables efficient development. True fixed bid also implies “waterfall” development and two assumptions: 1.) you have completed a thorough, efficient design phase, and 2.) requirements won’t change during the development process. Neither of these assumptions are realistic.

Fixed bid usually creates a mind set that change orders will increase costs. Although you could look for other areas to reduce scope to compensate for the cost of any new requirements or increased complexity uncovered during the development and testing periods, this seldom happens. It also means that a less than thorough job will be done in identifying unneeded features or features that could be developed at a more basic level. These will tend to be built as defined in the initial requirements whether they provide value or not. The above goes a long way towards explaining why “fixed bid” projects are almost always over budget and late.

But that’s not the greatest risk. What if you can’t get the additional budget needed to address the new and enhanced requirements uncovered and you have to deliver the project as originally specified, on-time and on budget. You now probably end up with a product that provides limited or no value and has difficulty gaining user acceptance. Even if it is launched rather than abandoned, the cost of forcing acceptance probably exceeds the additional cost of building a better application (of course those costs come out of someone else’s budget – so you can probably pretend it was a successful project).

Agile “fixed bid”, managing to a cap – change does not = increased costs

With Agile, the cap can provide the ROI comparison number needed to get project approval. It is as “fixed” as a “fixed bid”. The difference is the focus and how change is managed. Rather than focusing on how much money is being spent (on time, on budget), it focuses on how much value is being created (what are the features that provide the highest ROI for a given amount of dollars). Instead of changes in requirements and increased complexity being treated as surprises that need change orders, change is expected and its impact is being continually be evaluated to help ensure the most important features, those leading to greatest ROI, are always being worked on first and that features determined to be of little or no value are treated accordingly (just reducing the percent of features developed but not used from 49% to 25% is a huge win). With Agile, the entire team – developers, business stakeholders and users – is clearly focused on making sure you end up with the best product that can be produced for any targeted budget number.

Share/Bookmark

I’m approached by people every week that think they have a great “new” idea for a web startup.   The ideas run the gamut from those that aren’t yet technologically possible to those “new” ideas that I have received 10 similar calls on over the past year.   Here are some things to consider:

Think about the business need and revenue model first.  Who are the users (your “customers”), what is the application or service worth to them, how many of them are there, etc.   If you can’t envision generating a million dollars plus a year in SaaS (Software as a Service) revenue or in gross margin for an eCommerce business, it’s probably going to be an expensive hobby, not a business.

Make sure you can create a sustainable competitive advantage.  What are your differentiators?  If you have to say I want a site like “xxxxxx”, you are probably starting off on the wrong foot.   You already have at least one competitor with a customer base.  

• You need to make sure you have clear differentiators that are easy to explain to potential customers.   And, you have to understand that even if you have real differentiators, you will need to spend more marketing dollars to get that across in the marketplace than if your offering were more unique. 

Be realistic about the cost of developing and supporting custom software applications.   Although $50k-$100k may get you a standalone iPhone or Facebook application, be prepared for $200k-$700k+ for a commercial quality eCommerce or SaaS application that has scalability, security, usability and proper automated code tests for long run supportability.    

• Forgetting for a moment the cost of building an application that is solid and scalable enough to run a successful web business on, remember that you need to build a sustainable competitive advantage.   If your application only cost $50k-$100k to build, the entry price for new competitors, some of which will have much deeper pockets, is too low.   Even if it is a good idea, you most likely will just be paving the way for someone else to be successful. 

Don’t give up just because of the above. You still may be on the right track but need to do more thinking and planning before spending money on development. Here’s a quick checklist.

• Do I have unique domain expertise?
• Do I have, or can I get, a protected distribution channel?  (e.g. a spin-off with an existing client base)?  Or can I find a partner that can provide this?
• How much funding to I need, not just for development, but for marketing and operations?
• Where is the funding going to come from?
• Have I tested my concept with actual customer targets from both a functional and pricing standpoint?
• Should I be trying to build an application at this point, or build a prototype to test with potential customers and investors?  A PowerPoint prototype can done for $10k; a functional prototype can be build for $35k-$75k.
• What are my personal, or my team’s, strengths?  What skills am I missing for running a succsessful company?  How do I fill the holes?

My intent is not to discourage anyone from trying.  The web is still the wild west in many respects and the opportunities are there.   My intent is to help you prepare for success.   Too many people fail with great ideas because they use up all of their energy and resources jumping in unprepared and aren’t able to follow through.

Related Services: Custom Software Development, User Experience Design

Share/Bookmark

Agile development, when done right, results in better software at a lower cost. More and more companies are coming to this conclusion, but most are struggling with how to adjust their RFP and Governance processes to adapt.

The typical RFP process for custom software development is looking for a fixed bid, thinking this will provide budget protection and guarantee ROI. History clearly shows this is not true. Issuers expect to come within 10-20% of budget. Studies show that custom software costs can range from 50% under budget to 300% over budget. Why?

• Requirements are usually inadequate (though there is a very wide range if inadequacies.)
• The requirements produced generally have little to do with usability.
• Things change – requirements change, technology changes, the competition changes, etc.
• Too many features are built that aren’t used – studies show that 45% of features build under waterfall are never used.

Because all vendors know the above, they all take different approaches to responding to RFPs. Some try to provide a relatively accurate estimate by using historical patterns. This can be fairly accurate if they’re building an application they have done many times before using the same technologies.

If you’re trying to use application development to create or extend a competitive advantage, you’re likely building something new that no one else has built, rather than customizing something off the shelf. In that case, all of your RFP responses will be WAGs. Rather than pretending this is not true, focus on how you’re going to differentiate vendors and how you and your chosen vendor will work together to develop good requirements, adapt to change and maximize your ROI.

Think about your past choices based on the RFP process and whether you would have selected the same vendor (or any vendor) if you had know what the true cost was going to be. Was the highest vendor the one that was most knowledgeable? Was the lowest vendor the one with the least understanding of the complexity? Or was he intentionally providing an unrealistically low estimate, thinking he would make it up with change orders?

If total estimated cost isn’t a reliable measure, what can be?

Reliability is of course relative. But here’s one approach. Look at team composition and iteration costs.

Team Composition: To develop efficiently you need a core team with the right skill sets that stays together on the project and can jell, thus increasing development velocity. Does the team include project management, business analysis, information architecture, visual design, technical architecture, development and infrastructure resources? All are needed to create commercial quality, high performance, scalable, secure application the meet users needs (generally you need at least a 3-4 person team to cover these skills). You also need an approach to fill in non-core but necessary specialized skill. Does the vendor have internal resources for these areas or a plan to cover these deficiencies? Rate the vendors based on skill breadth and depth.

Iteration Costs: Calculate the iteration costs (generally 2 weeks) for the core team with an allowance for specialized resources. Compare the cost of the first 5-6 iterations for each vendor rather than the total estimated cost they provide (there’s nothing wrong for asking for expected total cost, just don’t assume it will be accurate).

Experience and Skill Match: Rate the vendors based on experience and skill match as it relates to those needed for your project. Don’t expect, or care, whether they have done something exactly like it in the past if you expect to create or retain a competitive advantage.

Compatibility: Agile development needs to be a collaborative process. Visualize how you would work with the vendor. Do they really follow an Agile process (daily scrums, test driven development, continuous integration, weekly demos, pair programming, etc)? Do they provide transparency to the development process? Do they require you to participate actively in the development process on a weekly and daily basis? The biggest mistake companies make when they use the RFP process is not getting to know the potential vendors. The responses get put is some evaluation spreadsheet, and final selection is often made by committees that have not participated in the requirements gathering or RFP process and often have no development experience. That works for some types of projects, but application development for competitive advantage is a creative, collaborative process. This is much harder to evaluate. The easy way out is to rely on quantitative metrics – but that often doesn’t translate to successful projects. Some companies use quantitative measures to get down to the 2-3 finalists and then use other criteria, including some of the above, to make their selection. This is not perfect, but seems to work better.

References: Find out if they are really using a collaborative process. Ask their customers how they are to work with, whether they are open a fair, and how the internal stakeholders and real users like the end result.

I’d love your feedback and suggestions.

Share/Bookmark

Most designers and developers today are familiar with the concept of Personas for describing the users of a system.  In fact, you can use the same concept for how you talk to business people – the consumers of your services.  Put yourself in their shoes, and your services will be better received.

One of the things that drives business people crazy when talking to tech people are the terms they use.  Here are a few to avoid, and what might work instead:

Some terms not to use with Agile development

• Agile iteration zero – I understand why it’s used.  It is the iteration before “real” development takes place.  Most business people start counting with 1 – iteration zero always leads to confusion.
• Agile backlog – call it a prioritized feature list.   To a business person, a backlog is bad – it means you’re already behind schedule.
• Out of scope – never tell your client (internal or external) something is out of scope.  If you’ve convinced someone to use agile (often not an easy thing), nothing is “out of scope” – you need to talk about where they want to place it in the prioritized feature list.

Some phrases not to use with clients

• “You don’t need that” , “Why would anyone want that”, and anything similar.  In most cases the business users have a pretty good idea as to what they need and even if they don’t, they will turn off communications if you start like that, thereby preventing the collaborative effort needed to reach a successful resolution.  Instead apply Dittmann Rule 1 - worry less about being right and more about being effective. Re-focus the conversation on their business goals and how that feature helps them reach their goals.   If you can help them get to their goal in a better way, they’ll generally jump at the chance.
• “I don’t know” - in response to why something isn’t working.  In reality you probably don’t, but if something isn’t working (i.e the network is down and 100+ people are losing productivity) the person you’re talking to is probably going to have to answer to someone up the chain – “I don’t know” is not going to make them feel very comfortable or serve as an acceptable answer they can pass along.   Instead explain how you are going to go about identifying the problem so that it can be resolved (e.g. it could be the router or the firewall, to isolate the problems we are going to do x,y,z), and when you are going to update them.   “I don’t know” spreads rapidly in an organization and creates ill will up and down the chain.  A plan for helping them can create sympathy.

I’m sure everyone has their own list, but the main idea is to think about how you would react to these terms and phrases if you were the consumer of services.

Share/Bookmark