The Product Playbook — Part 2: Product Delivery
In the previous article, we discussed an approach to do product discovery including sharing the application of some useful methods and tools. Leading over to the next phase and part in our ‘Product Playbook’ series, in this article, we will talk about product delivery. Delivery is the point at which prioritized product specifications are handed over to the development team or engineers to be designed, built and implemented. We will share details on how we do it at Sparrow Ventures, especially focusing on medium to higher complexity projects that require a tech team. Despite delivery being a technical topic, our goal is to also help non-technical individuals to gain an understanding of the processes of launching digital products.
Project complexity at Sparrow Ventures
As a venture builder that validates dozens of business models every year, we often work with very diverse projects, not only in terms of industry verticals but also technical complexity. When we start a new project and the team performs the product discovery, we not only identify opportunities and test them with potential customers, but also assess what is the minimum viable product (MVP) that can be built to validate our hypotheses in the market. Following, this results sometimes in projects with lower technical complexity, like Petcare, where we use off-the-shelf tools like WordPress, Unbounce or Shopify, allowing us to launch the product for testing in the market within days. This is possible because it usually doesn’t require tech team involvement and is designed and implemented by our product owners and designers. If venture projects are of higher complexity, like for the now carved-out smart fridge that is connected via mobile app, Snäx, a tech team joins in and is led by the product owner to effectively build the MVP. The latter is going to be the focus for the rest of the article, where we will share knowledge and learnings from our work at Sparrow Ventures with regards to more complex product delivery projects.
Product-related processes
Before getting into the techy subjects, let’s have a look at the processes to consider in terms of the product.
Product process
There are several methodologies used in software development today. Many companies, especially those that are tech-focused, apply some form of agile and lean development approach to their work, whether this is Scrum, Kanban or Scrumban, the combination of the two. At Sparrow Ventures, we are flexible and it depends on the situation, but generally, we use the best practices of Scrum for our product development process. We time-box sprints to around 2 weeks, use story points to assess what can be achieved in the upcoming sprints and so on. One aspect we have adjusted is the setting of daily standups. Instead of daily, we have it twice a week over video calls with our remote tech team. This is only possible through our frequent and transparent communication when it comes to relevant updates for the whole team. For this, we rely heavily on Slack and an approach sometimes taken is to write with bullet points in the morning what you have achieved and what you will focus on today. This enables us to keep meetings to a minimum and reduces interruptions during the workday.
Product backlog
Once the team has tested and validated solutions for a venture project, usually the product owner creates a list of features and other related tickets that the team may deliver in order to achieve a specific outcome. Here, we follow the general agile practice of creating a backlog, that includes epics and user stories. The product owner is responsible for the backlog but often involves other team members early on like the development team as they provide their knowledge and creativity and discover technical risks and dependencies, like checking or testing early on external integrations.
As mentioned earlier, we usually follow the scrum methodology. This means that we regularly groom and refine the backlog together with the development team. These sessions also give us the opportunity to break larger items into smaller ones and ensure that the high-priority items are ready for the upcoming sprint planning. These items are referred to as user stories, which are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. It’s recommended that user stories try to capture not only the functional requirements but also the user interaction and interface.
Prioritisation
It’s not surprising that prioritizing features rates high among the challenges faced by product leaders. It’s difficult to determine what to spend your and the team’s time, energy but of course also money on. For this, some common methods we often turn to for guidance is Impact vs. Effort and the combination of Impact, Confidence and Effort (ICE). These are relatively qualitative techniques, but it’s a great choice for new products and MVPs when you have a little amount of quantitative data available. What’s important to note is that you need to have done your discovery work so you have some confidence and an understanding of what the potential impact could be. The impact is usually measured in terms of user value and business viability, while effort is development time and complexity. Another method we often use is MoSCoW. The MoSCoW method is a prioritization technique with each letter standing for one of the possible prioritization categories and thus classified as:
MoSCoW works well with other techniques and helps to communicate with stakeholders what is required to be included in the next release and if time allows what could be included but not necessary for the release.
Technical related processes
Once the product-related processes have been considered and put in place, it’s time to look at the technical requirements.
Architecture
Before the developers put on the headphones and start coding, it’s very important to first clearly understand what is the architecture you will use for your tech product. By architecture, we refer to backend database structures, programming languages to build the frontend and talking to the database and where to host the data. Also, consider when is it worth building a mobile application versus building an application for the web browser.
At Sparrow Ventures we have combined technologies that allow us to cost-efficiently move to market fast and if required be flexible enough to be scalable and easy to hand over in case the project is successfully validated against its hypotheses and gets “carved out”, meaning to become an independent entity in our portfolio.
- On the backend, we use PHP7 with Laravel framework and usually MySQL, PostgreSQL or MariaDB as a structured data store.
- Frontend we use Facebook’s React and ReactNative to build our web and mobile applications.
- Infrastructure hosting we use Amazon Web Services (AWS) together with Docker, Kubernetes and Terraform, which are essential tools that help us building, changing, and versioning infrastructure safely and efficiently.
Another important aspect of our process is the use of boilerplate repositories. These are essentially templates for different project categories, for example, one for our backend, admin panel, websites and for mobile applications. By creating these templates it allows us to set up new projects relatively quickly, always using the latest versions of the frameworks (like Laravel) and it minimizes the switching costs for engineers when they join new projects.
Integrations
Integrating with other third-party providers is a common sight especially with the growth of Application Programming Interfaces (API). Before integrating with a third party, it’s important to do the necessary due diligence. At Sparrow Ventures, for almost every project we use third-party APIs. For online payments, we often use Stripe for Germany, while for Switzerland the goal is to use Datatrans, as they cover specific payment methods, like Twint and PostFinance. We also have more project-specific APIs. This could be integrating know-your-customer (KYC) using Video-identification or Auto-identification in the on-boarding process.
Deployment process
When it comes to deployment processes, which are the activities that make software available for use, such as merging code so everyone is aligned and making the latest version available to users. We really follow the common best practices out there in the market quite a lot. For this, we follow the GitFlow (https://datasift.github.io/gitflow/IntroducingGitFlow.html) branching strategy, which includes amongst other things to write automation tests for every feature we work on or have at least one additional engineer to conduct code review before any code gets merged. Once code gets merged, Jenkins builds new Docker images and pushes them into a private registry, which essentially is a convenient way to package up the application and server environments within the organization privately. Finally, deployments to our development and staging environments are done automatically, meaning without any further interaction. For production environments, we currently still require a final, manual confirmation to trigger deployments.
Product launch
When it comes to launching web applications there isn’t as much hassle compared to releasing mobile applications. When we build mobile applications we often do Beta launches internally, which is to get feedback on the product as well as for discovering issues that the development team didn’t find. For iOS, we manage this through Testflight and have started to use Bitrise for Android. When it comes to submitting a new app to the app store, we have sometimes had issues with the Apple review process, so it’s important to set expectations here as it can sometimes take weeks to get it approved. A critical part is also to have the analytics set up correctly and ready for launch. Here we use standard applications like Firebase and Crashlytics for mobile app analytics to give us usage and error data.
We hope that you found the product discovery and delivery articles insightful and that it gives you maybe also tangible methods that you can use in your own circumstances. Striving to share knowledge and insights, the proposed tools and methods along a product’s journey from ideation to implementation in this article are a reflection of one useful approach and show how we do it at Sparrow Ventures. In the next product related article, we will discuss product metrics and how we obtain quantitative and qualitative data.
