Developing a product involves a wide range of perspectives and opinions. It's tempting to create roles for various specialty domains and build large teams, leading to overhead and unnecessary alignment. Our base assumption is that a small, multidisciplinary team working towards clear north star objectives is more efficient. This north star can take many shapes and forms, such as improving scalability and uptime, increasing conversion, or new feature development. These objectives will evolve over time as your product does.
Setting product teams up for success
We've crafted a lightweight model with limited roles but maximum ownership to reflect this philosophy.
- Product owner: embodies specific industry or academic knowledge
- Product manager: shapes the product roadmap and orchestrates the daily delivery process
- Chapter lead: subject matter expert who assures consistency and training across multiple teams
- Delivery: individuals from various chapters delivering on the product roadmap objectives
Our chapters consist of the following subject matter domains:
- Product design: turning roadmap objectives into validated clickable prototypes
- Software engineering: front-end, back-end and embedded engineering
- Data science & engineering: structuring and activating data
- Growth marketing: attracting and converting the right user audiences
- Customer success: setting users up for success and turning them into ambassadors
We standardised schedules across all products:
- Sprint model: planning / daily standup / demo / retrospective
- Roadmap meeting: weekly sync with relevant stakeholders where we validate the next (functional) objectives
- Product chapter meeting: every 6 weeks we bring the whole team together to validate specific chapter quality standards. Each chapter has a default checklist that we run through, which gets validated with the delivery team and the chapter lead.
- Product vision sessions: periodic moments where we take a step back to get fully aligned on the overall product direction
Delivery vs flexibility
It's well-established that introducing flexibility into the software development process yields a net-positive business case in the long run. The simple underlying reason is that it's impossible to define all parameters upfront when building something from scratch, yet you want your engineers to make good, long-term oriented decisions in the interest of the product along the way.
There's a common misunderstanding regarding the daily activities of a software engineer. While creating new features is crucial, it's equally important to address technical debt, refactoring, infrastructure optimisations, and monitoring essential quality indicators (errors, security, performance, etc.).
The traditional waterfall model has rightfully been replaced with an operating model based on 'agile' principles. This allows each team to define its own flavour of agile, operating principles, and roles.
Operating principles we hold on to:
- Play the long game: success won't come overnight, but the best product will always win over longer periods
- Welcome change: priorities and requirements will shift constantly based on user requests and feedback
- Pull on the same rope: real co-creation is the only path towards sustainable value creation with shared tooling and objectives
- Choose progress over process: break through the roadblocks - build!
- Honour great engineering: celebrate delivery and codebase quality
- Raise the quality bar: the work is never done, always aspire for more and better
How we partner
Our partnerships reflect these principles. We simply want to set bold ambitions up for success.
There are 3 types of engagements we enter into:
- Service model: the created intellectual property will integrally belong to the client in return for a correct payment of fees
- Venturing model: a structural partnership in which we co-invest into a separate legal entity in return for a minority part of the equity
- Licensing model: we absorb the investment and we reserve the right to exploit the product to a broader market
Don't hesitate to reach out to firstname.lastname@example.org to discuss a possible cooperation.