6 ways how your company can benefit from developing your project like a startup
7 minutes reading time. Published 2020-04-18.I've helped to manage, develop and deliver countless different web-based projects. I've wondered how the entire project development and the delivery pipeline are so flawed for a while now. For quite a bit now. But the product development could be better. Much MUCH better.
The (web) product development for a client often looked like this about 15-20 years ago (and still does relatively often):
- a client comes to the agency
- the client explains their requirements
- the agency presents a quote
- the client accepts the quote
- the agency starts developing what was requested
- during the development, the client presents additional requirements
- the project goes over the deadline
- the agency finally delivers the project (and often over the budget)
If startups delivered their products like this, they would often go bust before first investment. Here are some things any company can do to get better results from product development:
1. Understand what problem you are trying to solve with the development
What startups do is explore the problem before the actual development starts. Talk to potential customers to understand what pain needs to be solved. They try to figure out the most effective ways of solving those pain points for the customers and how many resources the product frees for the customers.
What any company can learn from this
Explore the problem within the company. Try to figure out the root cause of the issues. You could use the "five why's" technique to get to the bottom of the problem, for example. Google it or ask me about it. Sometimes the best solution to fix the issue might not be new project development. I have different stories to share about this. You, however, might not see this while someone from the outside could. Because "We have always done it like this".
2. Test the potential solution before you launch into full-scale development
So by now, startups have assumptions that the team must test. Sometimes they start with developing their MVP product, sometimes not. I, while very technical, am a fan of low-tech solutions. I adore when startups manage to find low-tech ways to test their assumptions without building the MVP. In his book "The Lean Startup", Eric Reis talks about a team who tested their solution by talking to their potential customers. They tried what their product would do by doing everything manually.
What any company can learn from this
Do you even need product development? For a while now, I've suggested to my friends that ask me about building websites that they should not have a custom website built immediately for their new business. Go with services like Voog instead. They make it simple to test if your business will take off or not.
Only spend money when you are making money, or know that you'll make money back. Do not jump into product development before testing if a new project can even solve your problem.
3. Understand what is the Minimum Viable Product (in your case)
Once it is clear what is necessary, the actual development starts. But before that, teams usually explore what the minimum, which solves the problem at hand, is. Different companies and groups have developed various workshops for this. One of the most well-known ones is Google design sprint.
During exercises like this team writes down the requirements in the form of user stories. Those stories can be expanded, tested, deleted, reworked - everything to understand what works the best. Sometimes designers are included to build prototypes of interfaces. Including designers helps everyone present to understand what works and what does not better.
The result of the workshop is the list of user stories that everybody understands.
What any company can learn from this
Workshops like these not only help a team to understand better what works and what is necessary. They also generate documentation that is the basis of the quote. Most product agencies understand user stories, and price quotes based on those stories are comparable. One of the biggest problems agencies have is how the customer can compare our quote to our competitor's quote. This question comes up because each agency talks to the customer, ask their unique questions, and receives their responses.
This process isn't good for the customer because asking those questions agencies help the customer create an image of what will be delivered. The idea in customers head is never going to be what chosen agency will develop and will be the basis of future "I thought you'd do this too" questions.
Instead, invest some time (and money) into preparing user stories through some consultant or in-house product owner. The investment will pay back in several ways:
- It will serve as a roadmap. You can track your project progress by seeing how many of your user stories are complete.
- It will serve as a basis for user testing. Based on those stories, you can create your test cases to test if the complete stories.
- It will allow you to keep track of new things which will come up during the development. You can easily see which changes have been made to the original document and understand that all the changes and additions come with a cost in time and money.
4. Develop in phases
The distinction between a startup and a regular company is that the startups operate in an environment of significant uncertainty. For this reason, each assumption that the startup comes up with will be tested. Let's say they assume that developing feature X will increase their customer retention. They will then set goals for the feature. Goals are either met or missed, but the startup will learn something either way. But most likely, they will save time and money by not investing a lot into something that would not have worked.
What any company can learn from this
Build an MVP. Do not order big project at once. Doing development in phases will help you get to know your development partner better. Most importantly, though, it will potentially save you a lot of money. Consider this, which is worse:
- Potentially finding out early on that your project will not bring you the success you wanted and be able to stop at any time or
- Developing for a long time only to find out you've wasted a lot of time and money at the end of a long project.
There are many other benefits for developing in phases:
- You can evaluate progress better
- You can catch potential problems sooner
- You can put a stop to a process but still have a usable product while you switch partners
- You can much better change and manage priorities during the process.
5. Pick the right technologies
One of the most important things for the startup is to pick the right technologies. I've met several companies that have come to regret their technical decisions that they made due to the influence of resources available.
The problems that come from picking potentially wrong technologies are numerous. Still, for the startup, the most important ones are that development is slow, difficult and that the additional resources ( developers ) are hard to come by or expensive.
What any company can learn from this
Pick the agencies that work with technologies that are widely in use. Languages and tools with wide acceptance make it easy to find alternative partners. Due to wide acceptance, you can be safe that technologies have great support environments, and thus the development is faster and cheaper.
6. Invest in quality
What startups often do, is concentrate on development speed and neglect code quality tools and testing. This concentration on speed often happens because the developing team is not strong enough to stand up to pressure from business development. Developers often fail to explain that the increasing amount of refactoring, bugs and code smell starts negatively affecting the rate of new features released incredibly quickly. So when the business side starts asking, "why is this taking so long" it is due to neglecting essential things early on.
What any company can learn from this
Accept that code quality is essential for the longevity of the project. You'll probably want more features developed later on if the project was successful. Neglecting code quality will hinder the development of new features. You also need to understand that much like spade gets rusted if it's left out in the rain - the code accumulates technical debt by not having underlying software updated.
So while you might enjoy the cheaper quote of a company that does no testing, you will thoroughly hate the fact that at some point, all the development costs a lot, and the number of bugs is unbearable.
But wait, there's more.
There always is more knowledge that can benefit you. Unfortunately, one of the biggest hurdles that technical people face is communicating all this to their customers—some agencies are excellent at this kind of communication. Work with them. Trust them. If you are unsure which one to talk to - talk to me first.