Launch - Startups and Early Stage Companies

Launch is targeted towards helping startups to kickstart their digital product journey.

We get involved at the idea stage, validate conviction through fast and small feedback loops, and execute their digital product dream.

In today's age, a Digital Product strategy requires the team to have three core strengths

Context: An understanding of the business implications in your vertical and how your digital product addresses it.

Skill: Exceptional strategy, design, and engineering skills.

Planning: A product plan tailored specifically for your business vertical, environment and project needs


Validate Assumptions

We'll use rapid prototyping, user testing, recruitment, interviews, competitor analysis and data-driven insights to create and validate the business idea.

These activities help increase confidence and conviction in ideas. They also help refine existing products or ideas. A successful “Validate Assumptions” Exercise could lead to pivoting, stopping, or doubling down.

This allows you to validate your idea against the real world in a matter of weeks before significant resources are spent.

User Research: Conduct user research during the product ideation phase to gather insights into user needs, behaviors, and pain points. If we don’t directly have access to the users, ask questions to the business stakeholders that nudge them to gather the information for you.

Market Research: Validate data through market research periodically to stay abreast of industry trends and customer preferences, ensuring our strategies align with current market demands. For each trend, ensure you keep in mind how our target audience may be similar or different to other users.

User Testing: Validate data through user testing before product launch to identify and address usability issues, ensuring a user-friendly experience and enhancing overall product satisfaction.

  • Usability Testing: Perform usability testing during the design (via prototype) and development phases to validate the effectiveness of user interfaces and interactions, ensuring a seamless and intuitive user experience. Measure the metrics before and after a change is added.

  • A/B Testing: Conduct A/B testing during feature rollouts to validate hypotheses and optimize strategies based on real-time user behavior, improving overall performance and engagement.

Surveys and Questionnaires: Gather feedback through surveys and questionnaires to collect quantitative data on user preferences, opinions, and needs.


Code Architecture Set up

This involves setting up standard conventions, patterns, test coverage and automation strategies need to be followed across the project. This is where you set the bar for your code base.

This enables consistency in your codebase. Makes onboarding, contributing to the project and building features easily.

Projects with an architecture "fit for the needs" are able to release faster, with higher confidence and stability.

Linting: Your codebase needs to be consistent. All team members need to be able to write code that other members understand. We should be able to look at a function, class, or a set of them and know exactly what it does. Use strong lint rules and sharing sessions to ensure you have a codebase that is consistent, by virtue of which your product will be consistent.

Pre-commit hooks: Configure pre-commit hooks to run linting and tests on files that have changed. Commit as often as possible - it makes cherry-picking or reverting very easy.

Commit messages: Use commit messages as ADR(Architecture Decision Records), and IDR (Immutable Decision Records). Ensure that you have checks in place and the entire team is following the same commit message style. We create sprint release notes from the commit message using this tool.

Readable Code: Writing readable maintainable code is not subjective. There are industry standards that govern what code is considered readable and maintainable. Work towards ensuring a low cognitive and cyclomatic code complexity. Run your codebase through static code analysers with SonarQube to leverage best in class industry standards. This should be part of your CI

SOLID, DRY, KISS Principles: Use them! Nothing beats knowing your basics. Understand the principles and leverage them in your day to day.

Automation: If it takes a minute or 10 it doesn't matter, automate anything that is repititive. Nothing should have an exclusive dependency on one person or a small group of people. Have stricter access controls, but always democratise ability.

Testing: Use tests to design your feature and product. Chose the right test automation strategy - unit, integration, e2e, load, penetration, etc. Ensure each feature relies on the right automation to ensure no regression, and that the feature works as expected.

Multi Environment: Leverage .env files, environment specific file injection, Secret Manager, vaults or any other tool or combination of tools to ensure seamless compatibility across all environments. There should be no code change. Just pointing to a different environment should be enough.



Scheduled Scrum ceremonies serve as consistent checkpoints in the project journey. It's primarily focused at alignment in delivery execution, and hence addresses each phase of execution. These ceremonies create a clear path of execution eliminating any what, why or how questions during execution. It ensures everybody knows exactly what to do, how to do it, and why it needs to be done. It additionally includes a feedback mechanism where open and honest communication leads to better sprint-on-sprint collaboration. Backlog Refinement: Prior to these sessions the Product Owner along with key stakeholders must ensure that the backlog has been prioritised. These are one-hour sessions conducted once per week within which implementation team members will be briefed on the contents of the outcomes and the acceptance criteria for each of the items in the backlog, and will then issue story point estimates for them using planning poker or other mechanisms. It's important that each member already goes through the Product Backlog before the meeting. This is not a discovery session. Sprint Planning: This ceremony is conducted 2 days before the start of the Sprint. In most cases we run 2-week sprints. Prior to this meeting we need to ensure that the goal and the objectives of the sprint have already been defined and are clear to everyone. In this meeting we simply join, distribute the work, do a sanity check to make sure that we haven’t missed anything, the plan of execution doesn’t block individual, etc. This meeting should also account for any “aha” moment that the team members could have after the Backlog Refinement

Daily Standup Meeting: This is your daily check-in meeting. Each person provides an update on what they worked on since we last spoke, what they are working on, and if they are blocked on anything. Prior to this meeting each member must ensure that they have updated the board to reflect the latest status of their work. Other than the routine updates, use this meeting to share quick learnings that you have with the team - if it requires more than the stipulated 15 minutes consider organising brown-bag lunches with interested folks.

Sprint Review: Probably the most important ceremony - this is where you demo the objectives and goals that we've accomplished throughout the Sprint. The PM/Lead will conduct the ceremony starting by taking us through the Sprint Release presentation, followed by a demo after which the floor is then open for questions and feedback. Sprint Retrospective: The goal is to learn how to increase efficiency and effective of collaboration. With each sprint we should have learnings on what could be done better, or what we should be doing more of, or less of and those need to be condensed into actionables for the team. Sprint Retro's are geared towards the team and not individuals. During the retrospective it's important to remember the Prime Directive as stated below

Regardless of what we discover, we must understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. - Norm Kerth

Last updated