I have now been involved in approximately 350 web site and mobile application launches over 7 years spanning the full market spectrum: AU$200.00 to AU$450,000.00. I wanted to distill the top 4 most common client-side controllable issues that impede the speed to market, the launch-readiness and overall launch-quality of your website or mobile application.
For entrepreneurs, this should read as maximising the chances of success for your minimum viable product (MVP). For business, this should read as ensuring speed to market, ROI, minimising administration time, minimising distraction cost and opportunity costs.
Compared to other types of project management and development that I’ve been involved in, such as event management and property development, technology development is materially more difficult and complex. I am not alone in this view. Technology development can be a highly non-linear process where issues emerge in very unpredictable ways, have cascading and unpredictable effects on the overall system and have highly intractable sources.
There are a number of sources of delays that are addressed by a professional web development company. One major source of delays for amateur web developers stem from device and browser support. Websites can look and functional very differently based on the hardware and software used to access them. In Australia, there are approximately 15 economically significant carrier supported mobile and tablet devices, with varying operating system (OS) vendors, screen sizes, screen resolutions and OS versions in use. There are two dominant operating systems on the personal computer, with five dominant web browsers, all with many versions in use. This results in over 500 combinations of hardware, OS, screen sizes/resolutions and browser versions. Each one of these versions can theoretically render a webpage differently. Sometimes in minor ways such as minor positioning and alignment issues. Other times in massive and catastrophic ways such as a mini-site for a marketing campaign backed with a large marketing budget that doesn’t save entries on a mobile device. This could result in tens of thousands of entrants having a very bad brand experience. Professional web development companies use development frameworks and libraries that significantly mitigate cross device and cross browser support delays.
Conclusion: If your web development company is not using a dominant front-end and back-end framework, do not use them.
Other sources of delays in software development companies emerge from the following areas and you should ensure that your technology company doesn’t meet any of these criteria:
- A lack of good distributed version control software
- A lack of non-email based communication software for issue/feature discussion and bug/scope tracking
- A lack of highly technical account and project managers.
You must be able to speak to account managers and project managers who fully get it and do not need to hassle the programmers for every minor technical detail.
There are a four major pieces of advice I have for prospective web development clients looking to ensure their speed to market. All of these pieces of advice stem from the same idea, which is to clearly understand the goal at the start of the project, then use systems thinking to work backwards to understand the mechanical links, causative factors and non-reversible (or expensive to reverse) decisions along the way. As a result, do things in the right order and not hold any aspect of the project up.
Before I introduce the four pieces of advice, I wanted to outline what I believe is the ideal process that a client should undertake when embarking on a web or mobile project.
Step 1: What is the business or marketing objective of the technology piece?
Do not proceed past Step 1 unless you clearly understand and can clearly articulate the technology piece’s strong marketing purpose (either in attack or defense) and/or how it links to a business objective set out in a business or strategic plan. For example, an objective might be adequately described like this: This Facebook Page we intend to build will use a carefully constructed set of marketing content that encourages users to share with their friends a compelling opportunity for users to enter a competition which offers a demonstrably valuable prize to our target audience that fulfils part of our new customer acquisition strategy and online brand building objectives. This is a reasonably well defined answer because it links how the technology piece sits within the broad business or marketing plan, and outlines a user engagement process that is plausible. If you cannot construct a believable link between usage of your technology piece and a business/marketing outcome, do not build it.
Step 2: What are the critical success factors of the technology piece?
Do not proceed past Step 2 unless you understand what variables your technology is most sensitive to. In order to prioritise your spend and focus, you must know – or have a good idea about – any show stopping functionality, regulation or design attributes.
Step 3: How do we know at key milestones of the technology roll-out that we are successful?
Do not proceed past Step 3 unless you can clearly describe what success looks like in both the fullness of time and at key project milestones. Having some quantifiable targets say 1 month after launch, 3 months after launch and 6 months after launch will allow you to get an understanding of what kinds of metrics you need to measure from the launch date itself. The approach to technology now is to learn quickly from initial users and customers. You need to have the data at the end of the month 1 to make good decisions about whether you need to change something or stay the course. You need to know if you are doing the right amount of the right things. Further, this will allow you to set reasonable expectations around the results that are achievable for your budget to ensure the resilience of internal buy-in the project within your company. If you do not have a budget, one can be derived by working backwards from a risk-adjusted net present value of the commercial value of the targets that have been set out.
Step 3 can also enable to refine your budget. By thinking carefully about targets before embarking on a project and how they are going to be achieved, you are implicitly discussing payback period and return on investment. You may realise that to achieve a given ROI or payback period, you may need to adjust your initial functionality specification, budget or marketing strategy.
Step 4: What is our marketing plan to leverage returns from the technology piece?
Do not proceed past Step 4 unless you clearly understand how you are going to launch the technology piece. It is imperative that the launch and marketing strategy is fleshed out before building anything, otherwise you’ll almost certainty end up with a product that isn’t exactly the same as what you believe you can sell. The marketing plan must be very resolved before the product design phase because you must understand what communication requirements, content, commercial functionality and customer engagement functionality is required in the technology piece.
Step 5: What is my website or mobile application going to do and going to look like?
Do not proceed to Step 6 until you have used the information from Steps 1 through 4 to shape a crystal clear picture of the functionality requirements and design requirements of your technology. You need to be able to explain the sustainable value proposition of the technology piece both internally to your business and externally to the market. It must stack up logically, economically and in terms of priorities and opportunities costs on both sides in a sustainable way for whatever duration you have set out.
Step 6: Have I tested my concept, functionality and design with independent prospective users/customer?
Do not engage your technology development firm until you have actually validated your assumptions and tested on independent people if, how and why they’d use your technology piece. These test subjects must be independent – friends and family give bad advice for a number of structurally unfortunate reasons, even if they are in your target audience demographically or psychographically. They either have an agenda, or will be overly optimistic/positive because of emotional connections, or be overly pessimistic/negative because of jealousy or some other social force.
Finally, I come to my advice for ensuring speed to market for your web or mobile application:
Avoid feature creep – do not change things during the first major development push. If you have completed steps 1-6 properly, your first development phase should be very well defined. Changing it mid-flight is expensive and is often, in my experience, done for the wrong reasons such as reactions to the market which diverts the piece from the marketing or business plan. Feature creep, even in an agile development model, can slow down projects in non-linear ways and should be avoided in the first phase.
Devise, write down and test your marketing plan – it only needs to be short, but so many of our clients come to us without a clear idea of how the technology piece is actually going to be used by anyone. If this isn’t corrected at the start, we get to the end of the development process and need to retro-fit a large amount of new content, pricing information, e-commerce adjustments, new or different pricing methodologies, a freemium model, etc. This is slow and expensive.
Write the content first – so often, technology pieces are designed, then completely built and tested, then the client then spends weeks writing and refining content before the site goes live. Other times, the design might only allow for a certain content length without causing aesthetic degradation, and squeezing in heaps of content can have quite a negative impact on the user experience. Having the content at the start of the process allows designers to accommodate the length and nature of your content, so that there are no surprises at the end of the project. There is zero downside in having the content mostly resolved before engaging the technology firm.
Design everything – so many graphic design firms and insourced graphic designers represent a design as being complete, when in fact, there are a large number of workflows and elements that have not been designed. The developers then start on the technology build and don’t have any guidance on the design in many areas of the technology build. In mobile apps and websites, this is often things like how to display error messages or validation warnings on form submissions , how content is going to type-set with real content – rather than placeholder text such as tables and lists and how loading bars and progress bars might work. Often designers resolve all of the individual screens quite well, but neglect the interactions between these screens, which is very important and slows down the development process when clarity is required in these areas. Again, this can set the project back a long way if certain information comes to light about how the user interaction is going to work which results in a work having to be re-done.
I believe the following is very true: the time lost in extra design work at the start of the project getting the design exhaustive of all user interactions is significantly less than the time lost in corrective measures during the development process. If the corrective measures aren’t done, it is also significantly less than the market share/brand experience loss of a technology piece that doesn’t have polished user interactions.
So there it is, four easily avoidable traps when embarking on a new technology piece and some guidance on selecting a technology development partner. I’m always happy to field questions, commence and provide additional specific advice in this area, so feel free to email my assistant Bonnie (bonnie @ kdis.com.au).


