Trifecta
The trifecta is a work model - a core principle - that sets expectations, responsibilities and dynamics to build products effectively. As it's name implies, it's structured around the three roles that are defining the product, build it and deliver it on time.
1. Product - What?
Product is here to figure out what should be built. They answer the question 'What?'.
There is a process-y way to go at this, but many companies (small and big, young and old) are being very successful with an organic approach, so it's not mandatory. Don't torture yourself if you don't or can't do all the things below.
Here are some of the ways the Product role can find the answers to 'What?':
- Market research - Gartner quadrants, market analysis firms/reports, you name it. This is high level and frankly the company should have done this pre inception and maintain it up to date once in a while.
- Product Marketing - Customer surveys, usage analytics analysis, new revenue streams; anything the marketing team has collected in terms of next milestone. This or some of this can often be taken by product managers.
- CS/CX (Customer Support/Success & Customer Experience) - Not everyone has them, but if you do, they are often part of product, but they are strategically positioned to receive customer feedback on what works and what doesn't. Beware of the survivorship bias though.
- Stakeholders - Any other key stakeholders that has a problem, an interest and/or a demand. Can be operations, accounting, finance, compliance, and any of the other roles of the trifecta. Everything should be researched and validated.
- Vision - Now this is usually the part that everyone prefers. You YOLO ideas that make you feel great on reshaping the world as we know it. The less cynical way to look at it is, that this is the area where you define what the customer will want as they don't trully know what they want. It is easily 80% of the work when working on bleeding edge technology (deep tech). Very often, this comes from the founders, expanding by product leadership and through a back and forth with the different product leaders in the org.
There are more ways of course. They will depend on the structure of influences in the company and which departments have a support or control function. Regardless, successful outcome is a product line up, release structure, feature list with impact rankings.
2. Engineering - How?
Now that we know what we want, it's time to work on building it. The engineers will do that by answering the question 'How?'.
Engineering will do just that while retaining the most important elements from Product. This also means that the requirements from Product have to be sensible. To enforce this, the Trifecta works with each other not for each other. This is a critical differentiation of the trifecta vs what you've probably heard before from structure that resembles it.
To figure out 'How?' Engineering will go and look at:
- All stacks, Technologies and/or Providers - Which language? which framework? Full native? Web? Firebase vs AWS? AWS vs Azure? Self-hosted? Bare metal? Contractors for dev work? Do we use Atlassian? Testrails for our QA?
- Code base state - Is this a pit? What is a code debt nightmare? What's a house of cards? What's the perfect API-based engine we have that can scale to infinity?
- Skill set - What skills do we have at what level of maturity?
- Load and capacity - Do we have enough high skilled people available to work on said work? If so or not, what's the rough timetable (Project will help here)
- Current recruitment market conditions - Consulting with HR, you get a sense of your upward expansion in talent to beef up? What's our turnover to have a new hire productive? How much of this is related to our stack?
- Team dynamics - What team is critical for the product dev? Are they up to speed? Are they at the right level of maturity?
Their decision-making may require architecture meetings, exploratory R&D and definitely iterations. Ultimately, the success outcome is a multi-generational plan on how to balance new features, core technologies development and refactoring. (It goes deeper but not relevant here)
3. Project - When?
The Project role has often other names like delivery and program management. There are differences noticeable but at the role level they don't matter.
Anyway, we finally know what we want to build and how we will build it. It's time to figure out 'When?'.
At this moment, Engineering is capable of giving time frames but these are notoriously unreliable. That's because to provide accurate timeframe, you need perspective. I'll go in the details later, but in a nutshell, you need some distance to see the entire picture and a certain detachments from outcomes. This is functionally incompatible with what engineering needs: depth, focus and commitment.
Project isn't deciding how long something takes. Project allows Product and Engineering to come up to compromises by being a grounded sounding board to all dependencies at hand. That's also why in mono-products like a single iOS app, you rarely need a project manager. Engineers will easily assume the role and do it well.
In bigger settings, Project coordinates all work from the individual teams to the cross-functional collaboration - sometimes with external stakeholder - it gets to see the entire dynamic at play. Every meeting is an opportunity to identify conflicts in promises ("you said that..."), expectations ("I though ...") and responsibility ("I didn't know I was supposed to ..."); to make sure the progress is capture appropriately; to lay the work on roadmaps and timeframes.
Project is often the most powerful when the full owner the of project management tooling (Jira and alike). They work to continuously polish the process in place as to make sure every team speaks the same language.
Project will often either drive a meeting when there is a peer-to-peer coordination using soft skills. Project isn't the boss in the room, Project just wants information to be accurate. Regardless of who runs the meeting, if Project is involved, it will act as a minute taker. They will then communicate to everyone the outcome. It's an important step that realigns everyone.
In a nutshell, Project can build the path to figure out 'When?' by:
- Attend all stand-ups - It gives it direct insight in how engineering is working. Direct opportunity to raise upcoming conflicts and issues
- Run regular sync up with Product and Engineering - This is to realign all expectation with the latest reality.
- Kick off new work - To make sure everyone is starting from the same point.
- Own the project manager tooling - To define and maintain the engineering workflow language across all teams. You don't want 10 teams with 10 different ways of working.
- Communicate & document - To set where timeframe are available and make sure everyone is working under the same expectations.
Ultimately, this work gives the answer to when will the work be done. And when done right, the successful outcome is information that is available at any given time with minor update delay (< 3 days).
The Roles aren't necessarily matching 1 to 1 with people. In smaller companies, theses are hats that a single or more people wear. In large entities, it's easier to have full departments behind these roles.
For the trifecta to be effective, you need to promote a healthy back and forth between the roles. This is essential to adjust to the other roles' harder lines they may face.
As a rough schedule you can use is:
- Product <-> Engineering should meet once a week or every two weeks.
- Product <-> Project should meet once a week.
- Engineering <-> Project should meet daily or multiple times a week. Ideally, Project has people to be at daily stand-ups.
Last, remember that these roles don't report to each other. They are peers working together towards a common goal. They all need to carry their own weight so they all can do their individual work. They all depend on each other.