Recently, I gave a talk to a group of MBA students participating in the summer program at the Arthur Rock Center for Entrepreneurship at Harvard, about what to think about when building a digital product from scratch. It was an interesting challenge to try to boil down 10 years of learning into a couple of key takeaways for a group with lots of great business ideas but relatively little technical experience. There is so much to share, but here are the four ideas that struck me as useful for startups with opportunity, lots of enthusiasm and some budget.
Don’t underestimate the importance of great design.
Great design always meets the user where they are, and that can mean that it is entirely different from your own view and what you imagined it to be. You can only achieve the complete alignment with your users’ needs if you allow for an open discovery phase. You will be surprised what you will learn in addition to your already existing knowledge about your users. The discovery phase looks closely at user experience (the flow), user interface (the functions) and branding.
As a founder, it is tempting (and perfectly fine!) to map out a user journey and initial wireframes on your own to help flesh out the idea and identify unique features. However, as soon as you can, I recommend that you bring a team of analysts, designers and technologists together and also add colleagues who can offer a completely different perspective (e.g., someone from HR or Legal fields) on the use case you want to bring to life. This group can fill in all the holes and corner cases, point out expectations of users who will be brand new to the idea and make the application look special as well. Results that are absolutely worth the investment!
Select your backend technology with an eye to the future.
Many of the students in the group were roughing out prototypes using low-code / no-code platforms to test their ideas. This is a great first step, but not necessarily a long-term solution as it is the backend that will be the core of your software product as it business logic, algorithms, machine learning and data that make your product unique and valuable. The frontend, as shiny and visual and touchable as it is, can only be as scalable as the backend allows. You need to build in scalability from the start - Think big!
Another reason why you should start thinking deeply about the backend setup is your business model, which will be (in most cases) reflected in the backend structure. Take data, for example, which carries the most value of most software product related businesses nowadays. How to collect the correct data, secure it and transform it into something of value to you, is the work of the backend. Decisions on the overall logic, algorithms, etc. that are facilitating this process need a fair amount of consideration. Discussing different set up options and analysing pros and cons is an important step while setting the foundation for growth and the inevatible changes that you are going to make.
Again, here it is tempting to hack something together in a set of technologies with which your tech co-founder is familiar. This could be fine to get a prototype off the ground, but be prepared for a foundational rebuild based on the goals of your business model and the functional requirements as they evovle.
Stick with browser-based applications for as long as possible.
Now, back to the front-end choices.
If you have a product in mind you want to build, stick with web development as long as possible and iterate as much as you can to tailor the product to the exact user needs. Lots of companies have an Android or iOS app in their mind even though it is not yet clear that the functionality really calls for a native app. In many cases the functionality that is needed can be very well supported with a web app. And there are lots of advantages to it: Time and money being the most obvious. We recommend building browser based apps to test your assumptions and sharpen your vision on further feature development. Once the core features are validated, then you can consider moving to a native mobile solution that is optimized for iOS and / or Android.
Give Testing the time it deserves
Don’t rush through the testing process. There are many reasons why testing gets cut short: Tough timelines, pressure from stakeholders, believing that small changes won’t have a big impact, being tired of looking at the same flow over and over again, etc. Instead, plan lots of time for testing, both in terms of effort and elapsed time, it is crucial in the whole process.
To the surprise of many, the work of a tester starts during the requirement and wireframe phase, before there is even a line of code written. Testers can give valuable information on design and functionality from their vast experience, and usually start writing test cases based on wireframes. Once the tester has written out the cases, they can then take charge of both manual test execution and automated testing - investment in the later will yield great benefits as your product grows.
If you already hold a version of your software product in your hands and are in the process of iterating, you will likely hear or say this question a lot: “Did you do a regression test?” Regression tests are essentially a re-run of test cases, to make sure that modifications in already tested parts don’t cause new issues. It’s the most important part of ongoing development to make sure that what has already been deployed stays working.
Finally, in the last phase of the development process when your website or app is largely feature-complete, you can proceed with UAT - User Acceptance Testing, sometimes also known as Beta. During this phase, you share your product with a preselected user group, so they can test it and provide feedback. From experience we would advise to have a big enough group size to get a good amount of feedback back. Don’t be shy about sharing your product. If you came this far it is not very likely that someone will run off with your idea and try to rebuild it. They most likely won’t have the time, money and most of all endurance you brought into the project.
Build a multi-dimensional team
Finally, the best team is once composed of experts in design, backend, frontend, testing etc. since each domain is so vast and is more than most people can stay ahead of (not to mention keeping up with related areas!). This is the reality and waiting to find the one person (a unicorn) who can do it all will be a long search. Once the team is assembled, try to give them the autonomy and respect the difficulty of building clean, scalable components in each of these areas. At the same time, finding ways for each team member to take an ownership stake in the entire end to end experience is ideal, but noy easy since you need to balance focus on execution with perspective.
There are certainly many more best practices to follow, but these will help you get going on the product exploration and market testing phase while setting you up for a long, successful run.