The purpose of a tech startup is not to unpack an idea, rather to experiment, addressing a problem and creating an opportunity. The environment of startups is dynamic, unpredictable, forcing entrepreneurs to act quickly and learn faster, to find a market niche and acquire a repeatable and scalable sales process to find, win, keep and grow customers and generate revenue.
The schedule is tight, it’s hard to find the time to do reflective thinking on how to optimise the development. Most startups fail. Most of this is due to the lack of customers. To what extent engineering practices impact this high failure rate is still unknown, a fumble may crater the enterprise, so it’s a balance between being agile, focused on which early product features add value, and consider tasks that reduce the time to market.
The development process needs to be agile, incremental and evolutionary, embracing change, allowing development to adapt to the business strategy, with an iterative and incremental approach shortening the lead time from ideation to production to validation with rapid and frequent release deployment.
The agile process, adopting the lean startup philosophy, which provides a minimum viable product to systematically test and plan modification for the next iteration, is, in our experience, the most valid approach.
Through tsf.tech work with lean startup and agile development approaches, we’ve identified a few sure fire ways to help tech startups adopt a product development process that delivers the appropriate business value based on time, risk and resource constraints. This blog shares our experience, highlighting a few process-related priorities to keep in mind as you look to tackle development goals in both an effective and time-sensitive manner.
Embrace customer driven development
Startups needs to rapidly demonstrate that they’re developing a solution that fixes a real problem. Adopting the Lean Startup approach of ‘getting out of the building’, they should release often and engage with prospective users, iterating to optimise the problem/solution fit.
Startups must discover the real needs of their first customers, testing their hunches by defining a minimal set of features that add value. Successful startups embrace feedback and let the customer be the architects and act as designers in their development process.
It hurts, but embrace negative or contradictory user feedback. The uncertainty of startups must be reflected in an opportunistically tailored minimal process management to their short-term development objectives, adapting to the fast-paced learning process of their users to address market uncertainty.
When developing software, your process is simply a framework for how work gets done. This framework should provide transparency, allow for change, and support customer feedback practices in all aspects of the development process.
It’s vital to involve the customer/user in the process of eliciting and prioritising requirements. It’s better to move towards testing the understanding and definition of the problem, and understanding if the solution fits real needs, before the product goes to market.
Give the dev team freedom to be ‘heads on’, not just ‘hands on’
The pressure of time and scant resources can be both a catalyst and a destabiliser for startups. Simply, the mantra of ‘fail early, fail fast’ is a healthy attitude, and the main viable strategy for enhancing performance and success in a startup.
Adopting this approach, the tech team must be able to absorb and learn from trial and error quickly enough to adapt to new thinking and features. Working on innovative products requires creativity – which by definition doesn’t create linear workflows and runways to regular milestones.
For a successful tech startup, the dev team needs expertise and experience in its ranks to counterbalance the lack of resources. In addition, having previous experience in a similar business domains and having entrepreneurial characteristics are important elements of a startup tech employee’s skillset.
The effects of bad development style can be corrected by heroic efforts. The trick for a tech startup is to have effective, software engineering processes where learning is the priority. Don’t build processes which are best suited for future scaling based on the product route map too early, you need processes fit for purpose today.
Be obsessive about capturing user stories
If you were designing your own house, how much time and in how much detail would you spend describing to the contractors what you wanted? Many founder product owners don’t obsess about the detail behind their vision – they have their architectural blueprint, thy can see the big picture in their head, but when describing their vision, they leave out critical context that developers need.
Requirements can often be rushed, too general, cluttered, or fail to capture the underlying assumptions. On the flip side, developers can treat requirements as if they were handed down to them as carved into tablets of stone instead of treating them as an opportunity for discussion, exploration or even challenge.
If a startup product’s vision isn’t translated into detailed user stories and thoroughly vetted, explored and prioritised, you may end up with a product that’s exactly what the customer wants – instead of what they actually need.
Focus on creating use case documents for your product that provide discipline, clarity and focus for engineers, it can be a template for future product development, but keep a balance, ensure the use case don’t become so detailed in scope that it creates anxiety over the fine details.
Granted, startup companies are under the gun to hurry up and build a great product and find relevance in the market, but never mind about the shiny bells and whistles, focus on the user stories to get initial traction.
Project management is a light touch
The majority of projects fail if they’re not managed well, but in the startup context, project management doesn’t mean a fixed tracking and reporting system. Rather, it means understanding what needs to be built, ensuring the thinking on dependencies is transparent and fluid, and having a hand on the tiller, guiding progress.
It also means keeping obstacles and expectations visible, driving clear communication and being alert to the underlying energy and emotions. What’s needed is a sprint based plan of user stories and resources, reinforced at daily stands ups aimed to keep teams focused and aligned.
In the tribal nature of the startup environment, it’s more important to promote collaboration and foster better decision-making as you go along. Engineering activities must be tailored to the startup context to allow flexibility and reactiveness in development workflows. Decision makers in startups confront continuous unpredictability, the relationship between cause and effect can only be perceived in retrospect.
Applying rigorous project management methodologies to control development activities isn’t effective because no matter how much time is spent on analysis, it isn’t possible to identify all the risks or accurately predict what practices are required to develop an innovative new product.
You need a framework and a process map that represents all the essential engineering activities in the build, but flexibility to accommodate frequent changes in the startup context. It boils down to trust, based on the competencies of the team and the experience of the technical leadership.
Always be thinking like a user – test the user interface
A challenge with startups is that the product continually changes, often the by-product of the Build-Measure-Learn cycle. Therefore, at what stage is it right to overlay user tests? The ideal solution is automated user interface testing, end-to-end, or functional testing, best achieved by building these tests from day one instead of waiting and back-filling later.
However, time and resource constraints are such that the best way for a startup to effect this is to have requirements or user stories translated into tests that exercise each feature, under each possible user personna. By building these tests, an automated web browser can drive the user interface and make sure it works as intended. This keeps the codebase from moving backwards in production, and stops the presses until it’s resolved, or until they ‘fix the build’.
The benefit of emphatic testing at the user-interface level is an increase in product quality. This is because each UI test is akin to a contract that cannot be broken. If the tests are evolving with the requirements, they serve as a watchdog to make sure we’re not rolling backwards.
In thinking about where to spend the most time testing early on in a project, tilt toward the user interface because it inevitably exercises all the other layers. If the UI works, the underlying layers are probably doing it right. Early adopters can provide a time-efficient way to discover bugs and help refine the product road map. The more practical user interface-testing the better, and retrospectives can add a lot of knowledge to the team.
However, testing generally is an open-ended question for startups. It absorbs valuable resource, and when you don’t have a fixed view of what you should build, and probably are not enough users on the system where quality is of concern, keep it in perspective.
Code Reviews – an overlooked lifesaver
The argument in favor of code reviews is pretty straightforward. During a code review, when a bug is found, it’s location and cause is known at discovery. When it’s removed early in the development, integration and testing will be easier. During testing, when a bug is found, it’s location and cause is not known. Especially in multi-threaded environments, a bug can be very tedious to locate.
Simply put, it means code is continuously tested and integrated whenever an engineer commits code to the source repository and doesn’t just hand it over with a ‘throw it over the wall’ attitude to a staging server attitude.
However, the economics of time, talent and cash for startups means that most are running hard and fast toward a goal, and leaving a wake of technical debt behind them. The tech team has enough process in place, as well as checks-and-balances, that nobody can break things, so let’s come back and refactor the code later?
But quality should always be a concern, and in the end, the trade-off is going to be a longer build cycle to fix the bugs at a later date, so rather than ‘hurry up and get a product out there’, I favour a ‘slow down and do it right’ approach, because we are probably living with the new features of this release for a long time.
The payback is clearly down the road on the efforts of good code reviews done as you build. It creates a codebase that is delightful to work with for future engineers, a codebase which lives longer, is easier to refactor and can stand the test of time. Review all critical code, peer review all other code is my view.
Design for future releases when building current release
One typical strategy to improve time to market is to divide the product build into multiple releases with increasing feature set – hold your vision for the product but pivot on the product feature set. This provides clarity on the current build, whilst also ensuring the current version is a platform or future feature enhancements.
Unfortunately, under tight deadlines, developers can be driven to make decisions biased towards writing the least amount of code, short-term expediency forces them to cut corners, which later won’t support the next feature set. It’s vital that you determine the right depth or context at each version. See this version as a prototype, but part of a product growth strategy.
Designing at a too high level produces ambiguity and leads to lack of clarity in implementation phase. Designing at a low level tends to produce over design and create inconsistencies in the project. As with many aspects of a startup, it’s a balance and a compromise.
This is particularly important to startups because the first product is not fully defined and thus it is as easy for developers to fall into the trap of concentrating on the main features, whilst inadvertently building barriers into the code that restrict future development.
‘Done is better than perfect’ and ‘move fast and break things’ are slogans you might hear when entering a startup workspace. What stands behind those slogans is a misplaced bravado. It needn’t be that way. It is vital that the long-term product vision is maintained and reinforced during the build of the current phase.
Summary
A tech startup needs development processes. Whilst developers tend to see many of the mechanisms as unnecessary for small projects, the challenge is to distinguish the context where each mechanism is appropriate and effective. We need to continually identify which software practices’ benefits outweigh the overhead.
The goal of agile development is predictability and that breeds trust. Regular and honest assessments of how your product development process is progressing will enhance the comfort of your team to make critical decisions. Trust your people. This type of approach will encourage a more rapid and fluid response to change. Retrospection, and how you adapt to requests for change, will shape your team and help pave the way to a better outcome.
Given the adrenalin of a startup, it can be enticing to ‘fly by the seat of your pants’ development, but if you don’t follow a degree of discipline and hold some process, it will be hard to predict results. Not all processes are created equal however, so it’s important to periodically re-evaluate your processes and look for ways to improve.
