How Does Product Work with Engineering at Manifold?
How Does Product Work with Engineering at Manifold?
Different companies, product teams, and people will have a different process to create a seamless transition from product to engineering. At Manifold, we’ve iterated toward a process that keeps design and engineering aligned with product and has increased our velocity in being able to ship product.
One Product Development Cycle at Manifold
Let’s take a look at a typical agile cycle of product development.
Note that this is one cycle, we would ultimately take this back to the customer to test and iterate
The steps are clear and linear. As product people you know we always start with the customer, that’s either through customer interviews, support teams, funnel data, etc. Those insights turn into the problems product defines for design. Designers are here to solve those problems in an elegant and beautiful way. Then those wonderful designs get handed off to engineering and finally out the door,
🎉 Woo! 🎉
Except that’s not actually what happens. Here’s what the actual cycle looks like:
In this cycle there are more steps, a lot more feedback, and many more iterations before the feature get’s shipped. This is great! This is what we want, means we are agile, empathizing with customers, getting engineering input, and ultimately building something that customers want to use.
But it’s also messy and really hard to coordinate. As the product manager, it’s part of your job to make sure the ball keeps moving through these steps so that product can be shipped.
Different Tools for Different Teams
Speaking of messy, tools are not all created equal. There are many options for tools for different teams to use, all built to enhance the workflow of specific teams.
All these different tools make keeping track of work cumbersome and it can be confusing to find where the work is tracked. But I believe there’s no one tool that would work best for the needs of all the different teams, so I like working within what the team has determined is the best for them.
This is the same philosophy that’s driving the Manifold marketplace. Sure you can use AWS products that are cheaper or perhaps more convenient, but we know developers want choice and to use the best of breed services. Selecting the tool that’s best for the job is what we’re all about.
How do you (PM) determine when the feature is ready to go to design?
I start most design asks with a PRD (wireframes if necessary) prior to kicking off with our design team. I say most because there are exceptions, such as short iterations or design driven changes. If you look up how to write a PRD, there are tons of articles out there on the topic.
The PRD is a place for designers to start and refer back to during the design phase. It should answer questions like:
What goal are we trying to accomplish?
Who is it for?
Why are we building it?
- What are we building?
Once you’ve answered those questions in your PRD, you’re ready to pass the ball over to design. At Manifold, this means creating a Trello card, prioritizing it in the ready column, calling it out in design planning on Mondays, and a kick off call with design if necessary.
How do you (PM) determine when the feature is ready for engineering?
Once the design team has some straw man designs, I like to bring in our product engineer to get their feedback on feasibility and lift. Another important reason you want to loop in your product engineer early is to get engineering buy-in. It’s my goal to align and rally all the teams around shipping this feature and it starts with getting buy-in.
Once I’m confident there has been enough feedback and its design ready, it then moves from Trello into ZenHub. I make the ZenHub issue in backlog with all the relevant information (goal, why, designs, tag stakeholders, labels, etc) and prioritize the ticket in the Friday Product x Product Engineer syncs. It then moves into the ready column and prioritized with other items, the top card in the ready column being the most urgent item to work on.
At Manifold, this means the feature is now officially passed over to engineering. It’s important to note that because engineering treats the items open in their backlog as ‘passed to engineering and engineering is responsible for getting it done’, there shouldn’t be tasks that are passed to engineering with missing designs or context.
The ZenHub issues created should have enough information where an engineer can pick it up, work on it, and deliver. There will always be questions and a need for clarification, and that’s encouraged, especially for more complex projects that require check ins with design. But the engineers shouldn’t have the ticket if they don’t have all the items they need to implement (copy, designs, acceptance criteria, etc).
How can you (PM) better coordinate the whole thing?
Being open and responsive to questions and clarifications through this process is extremely pertinent. If you’ve read my post on product management, I talked about how a lot of my role is to unblock the team. If design needs feedback on InVision? Be responsive to giving feedback. If engineering needs clarification on a design aspect? Coordinate the sync that needs to happen between design and engineering. Is there a question about priority? Be open, responsive, and decisive so the team can move forward.
How do non product people get items into the product pipeline?
You might be thinking, how does anyone not on the product / design / engineering team get things into the product pipeline? If you can, coordinate with your product manager to make sure the items that you need done are prioritized and will get done by the due date.
Try to work within the tools that the team uses. If you have a design ask, put that ask into the design Trello board with a due date and requirements. If you have an engineering ask, create a ZenHub issue with a due date and requirements and alert the product engineer. Creating the Trello or ZenHub issue also allows you to track the work and be informed of how your ask is progressing.
Lastly, be open and responsive to the design and engineering team if they have questions or need clarification. Tasks will remain blocked until the team gets the context needed to move forward.
While this process works well at Manifold, it might not translate well over to your company and your team’s working style. The important bits that will be transferable as a PM are:
Unblock wherever you can to keep the ball rolling
Wade through and filter the noise so your team can focus on shipping
- Be open and responsive
At Manifold, our team functions like a well oiled machine with this process in place. Hopefully you’re on a really dope team that you want to spend all your minutes with because working in such a cross-functional role is amazing, exhausting, and rewarding.
💅🏼 Cover art and images by our amazing designer Meg Smith 💅🏼