Strategies that adapt to dynamic needs: Product frameworks by company stage
One size does not fit all for product frameworks. How do you right-size your process to optimize strategy and execution?
Start-up founders and product leaders often find themselves in a predicament: while the field of product development is well-documented, fitting a process in at the early stage of a company is a different ballgame. It may be difficult to know where to start.
When a company is still in its early days, there will likely be pre-product, pre-launch, or pre-product-market-fit stages. This requires a high degree of agility in all areas: what you’re building, how you’re building, and what your team looks like.
Defaulting to resources for bigger companies or more mature teams risks having too much process, and consequently slowing down the team with meetings and red-tape. Building out a process “by the book” isn’t worth sticking to if it risks momentum.
how DO you implement a product development framework at the early stages, while staying flexible?
Continually evaluate product initiatives around goals
Building out a process is much like building out a product: it is best to start with grounding in the “user goals” or, in other words, by asking at each step: “What is the goal of the product team in this current moment?”.
Then, to make sure your process is grounded in real-world application and not text-book dreams, consider the following principles:
Structure is a communication tool
Structuring a process is mainly a way for collaborators to understand what is going on, why, and what to expect each step of the way.
Orient around handoff points
Handoff points are critical to the success of a process. Does everyone know what their role is and when they fit in the process? How might you structure this in a way that doesn’t feel waterfall but sits within a mode of continuous development?
Bias towards written communication
If it hasn’t been written down, it’s almost as though it hasn’t happened! Having a written record in a consistent place allows for the full team to be on the same page about what is happening and when. This responsibility is shared – whoever is driving the process should be encouraging documentation, but all involved should be part of the effort.
Consider the appropriate time frames
This is likely the biggest difference between larger teams/companies/initiatives and smaller ones. It is important for your process to be realistic about the timeframes, while creating space for the unexpected.
Stay rooted in company goals - as a business and as a group of collaborators
Ensuring there is alignment around the “endgame” is crucial to keeping the rest of the process chugging along. If there are misalignments with what the goals of the team are, it is likely that the process will begin to fall apart. If the process deviates from the current goals of the business (maybe too much work for the team that is moving fast), it risks being abandoned. As goal posts move, for the team and product, stay flexible in changing up the process to meet them.
How this differs in the later stages of a company
Later-stage companies are often spread across multiple teams and longer-term goals. While many of the principles above may apply, an additional one might also be important:
Don’t reinvent the wheel: The standard phases of agile development are commonly known and understood. In order to get to consensus fast on a way of doing things, consider starting with some of those standards and working from there.
Why do this now?
By starting with a focus on goals, the process ensures immediate relevance and practicality. Structuring the workflow as a communication tool fosters clarity and reduces the risk of misunderstandings among team members. Addressing this early on not only streamlines the development process but also sets the stage for sustainable growth, preventing potential pitfalls and aligning the team toward shared objectives.
how We Do: Implement/Adopt these principles in practice for a product process at the early stage
Use structure as a communication tool
Rules (Process) 📝
Start with a rough framework for how you’d expect the team to work to get a product or feature out the door. This document can be shared with all team members to provide a clear understanding of the overall process, including goals, timelines, and dependencies. Regular updates or meetings can be scheduled to review progress and ensure everyone is aligned with the established structure.
These steps are generally: compiling hypotheses, testing hypotheses with users, designing, testing designs, and coding.
Write down what you see those steps being and (…spoiler alert) orient around handoff points.
People 🫶
When proposing a structure, think first about the phases you want the team to hit, and why, and not about how they should be met. People work differently, so some may need a meeting at each step, whereas others will be comfortable working through stages asynchronously. Start with the structure and then ask the people who will be working within the structure how they prefer to work.
Orient around handoff points
Rules (Process) 📝
Build clear moments in the process when various stakeholders will be brought together, and decisions will be made. This will protect the “doing time” in-between moments of collaboration. Consider when founders, engineering, and GTM stakeholders should be brought in and the cadence/frequency this should be done. This is also a good moment to establish who will make which decisions, and when.
People 🫶
Documenting a process is a good moment to get everyone aligned around roles and responsibilities, and ensure that it is clear when decision points will be, and who will be making decisions at each decision point. Again, people are different, and the process around decision-making may differ by team. Just remember to…
Bias towards written communication
Rules (Process) 📝
It is vital to establish a centralized platform, where all important information, decisions, and updates are documented in writing. Consider this a time capsule for future you (or future PMs, designers, and engineers who will join as your company grows and expands). The most important thing to document: decisions made. How did you determine a given user problem? ICP? Feature specification? Focus here more on writing down the answers future-you might ask if you don’t remember the meetings happening for current-you. This way of documenting will help you in the future, but will also help your (current-day) team members and provide transparency across the entire development process.
People 🫶
The best way is to lead by doing, redirecting the team back to their Wiki of record (Notion, Google Docs, Confluence). Make sure everyone is on the same page about why this is so important – and try to leverage this as a tool to save meeting time (“Would you mind making a document or Loom about what you’re thinking for me to review before we chat?”)
Consider the appropriate time frames
Rules (Process) 📝
Start-ups tend to move faster than bigger companies, and can't afford to linger in brainstorming, researching, and speccing for too long. You want to be coding, shipping, and testing as fast as you can. So, think creatively about how you can fit in the research and brainstorming while not losing development momentum – maybe it’s doing a brainstorm on a Monday and a design review on Wednesday.
People 🫶
So much about supporting the people building at a startup surrounds managing their stress! The structure of a process helps ground everyone in what is coming next (and reminds them which stages are now complete). It also helps ground nebulous timelines in clear milestones, even if the features at each stage are still a WIP.
Stay rooted in company goals
Rules (Process) 📝
Every decision that is made to the product or process should map back to the goals of the business at the time. Ask yourself: “Does this change get us closer to solving Y for the [end user or team building the product]?” Be careful early on to not implement a process for the process’s sake.
People 🫶
Reorient discussion about ideas for process in the “why”. “Why are you suggesting we pursue that technique? What problem are we experiencing that this will solve?” This will help the process from becoming too bloated.
Tools 🛠️
Google Docs/Notion/Confluence: This is the source of truth for all the items you’re documenting, as well as the process you want to refer back to. Ensure this documentation is in the open, so anyone at the company might be able to reference it.
Brainstorming Tools (Figjam, Mural): These tools might bring to life the cycle of a process, or offer the chance for many people to hop on a call to work through ideas.
Loom: Before scheduling a meeting, ask: could this be a Loom? Generally, if a meeting on the horizon looks like it will involve 10 min or more of screen sharing, opt for a Loom or doc instead, and keep the synchronous discussion for, well, discussion!
Calendar: Your calendar is generally a preview into the process you’re using. When defining handoff points, decision moments, or brainstorms, chances are you will want synchronous time. If you are sharing progress, Loom or other documents might work better.
Actually Actionable
An example of how a process might be well documented:
Before you go
As startups inherently move swiftly, implementing these principles now is crucial for streamlining development, mitigating stress, and establishing a foundation that not only supports the current team but also paves the way for sustainable growth and success. “Process” doesn’t have to be a word synonymous with “big company bureaucracy” – at any stage of the game, it is vital for your team to consider how to structure the way they work through building together!
Writer: Sophia
Interested in working with Sophia through of All Trades to transform your product operations? Email founder@weofalltrades.com for more on how to bring her in as an embedded operator in your startup.