Janet Brunckhorst

The fundamentals of prioritization are not too different when you're the first at a company. But in the early stages of a company or product, it's even more important to focus. At an early stage company, or a new product at an existing company, chances are you're finding product-market fit. When thinking about prioritizing work in that context, you need to be crystal clear on the metrics that matter, and laser focused on moving them. In my experience, developing and testing hypotheses is a great framework for this stage. You simply can't afford waste, so understanding what you're trying to achieve, and then explaining to yourself why your proposed feature/deliverable/problem will achieve that outcome, is worth spending time on up front. For everything that you're planning to build, take the time to create a test plan. And always look for the fastest way to disprove your hypothesis. Here's a simple example plan: 1. Hypothesis: "if we do x, we will achieve y" is a good format. 2. Method: How will you test this? If you can do it without building any software, so much the better. 3. Metrics: How will you know if this passed or failed? Be rigorous here! Failing an idea early can save you later. 4. Results: What happened? Document and analyze the actual against your hypothesis. 5. Call it: Did it succeed or fail? Invest in the successes, learn from them, and keep repeating the cycle.

I'm a strong believer in "just enough" process, so my answer to questions like this is always some version of "it depends"! The one piece of process that every team must have is a way to reflect on, and incrementally improve, they way they work together. You can call this process whatever you like - "reflection", "retrospective", "after-action review", "post-mortem" - but it is imperative to building an effective team. This practice will inform the way you introduce and evolve processes as your team grows. Here's the lightest-weight retro format I've ever used, which is a great way to get started: Format: individual stickies brainstrom (one idea per sticky) Time: 30 minutes to one hour Frequency: Every one to two weeks Method: * Each person responds to the "I like" and "I wish" categories on individual stickies - timebox to 3-5 minutes * Each person shares their stickies * Affinity mapping: cluster similar ideas together * If needed: dot vote on the things that are most important. Be careful not to always prioritize the concerns of one group, though (eg, if there are more engineers than any other role, how will you ensure you also address concerns from other roles?) * Discuss your highest priority topics, with a focus on understanding the cause and generating ideas to make it better. Retro isn't a venting session! * Agree on the things you'll try, and if appropriate, who's responsible for making it happen. Categories: * I like - the things that worked well in the preceding week or two * I wish - the things that you wish were different * We will - the group's commitment to change over the next week or two There is literally an entire book on this topic: Agile Retrospectives, by Esther Derby, Diana Larsen, Ken Schwaber.

There's no single right way to structure any team. Some essential ingredients to creating an effective org are to create a structure that: * Supports cross-functional work * Aligns teams to customer problems * Encourages knowledge sharing * Provides for growth Your org structure will need to change as the company grows. And you will always need to account for silos, especially once the company grows beyond about 20 people. No matter what your org structure looks like, there will be silos, and you'll need to create and support communication channels to bridge between them. Some silos are better than others - I would always recommend that Product Managers be part of a cross-functional team, along with design, engineering, and other disciplines. Creating a silo between PMs and designers or engineers is going to create far more headaches than a silo between a teams that work together to build particular pieces of the product. At Aurora, our product team structure is designed around our customers' problems; specifically, around the lifecycle of our customers' projects. Putting customer problems at the heart of your org design helps to ensure that your teams continually focus on solving those problems.

I generally think in terms of OKRs rather than KPIs, so here let's agree that we are talking about some shared measure of success! On our teams, Product Marketing is responsible for all communication about the product or feature to people outside the Product-Eng-Design org. They're our liaison to the outside world! That includes: * Creating campaigns and collateral for customers * Developing positioning documents * Developing and rolling out enablement materials for go-to-market teams * Implementing campaigns and marketing events (eg, webinars, content marketing, etc) In terms of shared goals, product and product marketing have their own metrics that they use to track success. Where we need to get aligned is around higher-level organizational goals. For instance, I once worked with a team who launched a highly requested feature designed to increase conversions by existing users. After launch, the conversion metric didn't increase as expected. However, the team also noticed that surprisingly few customers were trying the new feature. The PMM on the team immediately kicked off a piece of work to rethink enablement and customer messaging around the feature, while the Product team dug into whether the feature wasn't solving the problem as intended. As the two disciplines tackled the problem from different angles, they were able to create more insights into what incremental improvements could be made, and drive more value for customers. 

The most important process you can set up is a retrospective of some kind. I talk about this in more detail in another answer, but as you add people, ensuring that you have ways of sharing and improving your processes is fundamentally important. Any process you introduce should have a strong reason for existing. While company breakpoints might point to the need for specific processes at an organizational level, within a small product team it's less prescriptive. But since you're product people, you have tools for this! As your team grows, start by identifying the problems. Once you've defined the problem, you can add process to address it. You don't need to reinvent the wheel on the solutions; someone else has certainly solved this problem before! But understanding the specific problem your team needs to solve is essential. Quick reference list of processes you may need: * RACI matrix * Shared product definition documents (Product Brief, PRD, etc) * Clearly articulated user stories for engineering * Mocks/designs attached to other documents * Cross-team/cross-functional standup meetings Here are a few common examples problems that growing product teams experience, and possible solutions to them. Problem: Who Does What? When you're small, you can all just pitch in. As you add people, you need to add clarity about where one person's responsibility ends and another's begins. Solution: A RACI matrix is a good, simple tool to clarify roles and responsibilities. A quick meeting to agree who is Responsible, Accountable, Consulted and Informed can go a long way. Problem: Cross-team visibility. With one PM, you have one person who knows everything that's being worked on. As you add more PMs, it can be hard to keep track of product activities. Solution: There are lots, including buttoning up your roadmap. A "scrum of scrums" style meeting can also be great. This is a term borrowed from Scrum, where representatives of each team gather for a standup meeting on a regular cadence (usually once or twice a week). Keep it standing, keep it to 15 minutes, focus on what each team is doing now and where there are blockers. Problem: Decision tracking. So many decisions are made every day in software, and losing track of them is a huge pain point! Solution: For a single project, a decision log can come in handy. But if your problem is that you don't know what decisions are made about the product direction or implementation, it might be time to review your documentation overall. Make sure that teams are creating and maintaining product briefs (or Product Requirements Docs), associating them with the latest design mocks, and reflecting that work in user stories/engineering tasks.

Great question, and it doesn't have a single answer. One thing that is important is having a consistent, accessible, forum/location for people to see: * What's been released; * What's coming up; * Metrics; * Issues/outages/major bugs. The details of how you do this will depend on a few factors: * Size of your company * Whether you're distributed, in-person, or hybrid * The type of space/collaboration tools you use * The team culture For example, a very small, in-person team might rely on a weekly Iteration Planning Meeting and some physical information radiators on the wall. A very large, distributed team might use a monthly all-hands for high-level updates and a formal product roadmap that everyone can access. As your company grows, you'll also want to collaborate with other teams on sharing updates. For example, Customer Support or QA teams may handle centralized communications about bugs and issues that affect customers, and Product Marketing may create a customer-facing product roadmap for got-to-market teams to use. Selecting the tools, forums and cadence that best support your team's needs, and then being prepared to change them as your team grows, is the most important thing.