How Product and Engineering Teams Collaborate
They have different responsibilities and workflows, but focus on one common stakeholder: the customer.
To learn more about the best strategies for collaboration between Product and Engineering, we spoke with Brock Wilcox (VP of Engineering) and Catherine Colwell (Senior Director, Product) from Framebridge.
The conversation below has been edited for length and clarity.
What is Framebridge?
Catherine: Framebridge makes custom framing easy and affordable. We have an online experience as well as retail stores.
Every frame we deliver is unique in some way and each one is hand built in our factory in Kentucky. That makes what we do from a product and engineering perspective very complex.
We’ve divided our engineering teams to support those different verticals: Retail, Operations (Manufacturing), and ecommerce.
How do Engineering and Product align on strategy and execution?
Catherine: There are two different kinds of alignment.
The first is unique to Framebridge: Alignment across Operations, Retail, and ecommerce.
Having alignment across the teams is incredibly important. We want to be clear on what our business goals are and ensure we have cross-team projects we work towards together.
We’re highly dependent on each other.
Let’s say our merchandising team comes out with a new feature, like mat engraving.
- We have to build the side our consumers see where they add that engraving to the frame.
- Retail has to build the functionality to sell that in our stores.
- Operations has to build the functionality to execute on the manufacturing side.
We have our individual priorities we focus on but when we have these larger projects, it’s important we stay aligned.
The second thing is the alignment between engineering and product.
Brock: That’s where we get into feedback loops.
We have what we want to do across all three teams. We have to figure out the business dependencies and the technology dependencies. We have to unravel the path towards that and the path towards the future. Also, you have to figure out how hard things are.
We do things in passes and iterations.
We build the list of what we want to do, figure out how hard it’ll be, and use that data to go back to Product and recommend improvements.
Catherine: From a tactical perspective, we have an annual, quarterly, monthly, and sprint-based cadence to our planning process.
On an annual basis, we set business goals: Strategically, what are we trying to do?
Every quarter, we figure out what we are trying to achieve and what that means for each team.
Then we do check-ins each month and with each sprint.
Engineering is involved from day 1.
We discuss trade-offs:
- How do we build things with the future in mind?
- How do we make decisions we won’t regret next year or the year after?
- How do we trade that off with building things quickly and hacking?
COVID-19 is putting that to the test. We’ve worked hard to make smart engineering decisions that we can grow with as an organization.
We’re at a point right now where the priority is to move quickly.
Hack it. Get things out the door. Make sure that this business is still around and stands the test of time.
How does communication and collaboration work between the Product and Engineering team?
Catherine: I know that if we don’t include engineering from the start, we will fail.
But you have to prepare engineers to be involved in that process. You can’t bring an engineer into that process without context or they will just jump to solutioning.
That’s difficult when we’re brainstorming, thrashing through requirements, changing directions, and don’t know what we’re building quite yet.
Have a conversation with the engineer and get them comfortable with that. Repeatedly touch base with them to find their sentiment and feelings.
They are an important voice to be in the room.
Brock: Communicating what phase we’re in across the board is harder than you expect and very important.
Developers typically tell us they want to be brought in earlier.
Interestingly, when we bring in folks when we haven’t determined what phase we’re in, I get feedback from engineers that they don’t know what they’re building.
Catherine: Some engineers are comfortable with it and others aren’t.
Leaders of engineering teams need to be comfortable with it because they have a seat at the table. They need to be comfortable with ambiguity. Understand that we don’t know exactly what we’re building and help guide us in directions that make sense.
In the same way our CEO and CMO are stakeholders, Engineering is a stakeholder. They have a stake in what we’re building and I work to ensure their happiness and their considerations in everything we do.
But the way I talk to engineers is very different from how I talk to my stakeholders. Everyone has different concerns.When you talk to engineers, they’re thinking about edge cases: “Well what about this case?”
They take the most complex scenario and ask how it might affect the situation.
When I’m talking with consumer facing stakeholders, I simplify: This is what the most common experience for our users is going to be.
Brock: I think of the product manager as a member of the team.
They are leaders in the team in many ways, but they identify and act as members of that.
Catherine: There’s a quote:
“Product management is leadership without authority.”
The engineers on the team don’t report to me. But along with the lead engineer I feel like a leader because I’m accountable for the work they deliver.
How do you set priorities for Product and Engineering?
Catherine: Everything we do is rooted in customers.
- What do our customers want to buy?
- What are their pain-points?
- What are their experiences?
We start with what we’re delivering for our customers and the experience we want them to feel.
You can achieve that outcome in a lot of different ways. You can make all your stakeholders happy if you ground yourself in delivering for your customers.
Brock: The instinct for folks when working directly with customers is the customer is always right.
When working with manufacturing, similar to working with software engineers, their answer is no. We need to keep this simple; we need to streamline things.
The key is making sure we have a universal approach. That approach is generally around the customer and setting expectations for all of us and the customers to get what they need.
How are the Product and Engineering teams distributed at Framebridge?
Catherine: One of our challenges is that Operations is more waterfall and Consumer is more agile.
We are constantly iterating on how we support our Operations organization.
If we release a new feature on the factory floor, that can be incredibly disruptive to their daily work.
They are a well-oiled machine and moving a button from one corner to the other can put a huge pause on operations for a day.
Additionally, our manufacturing facility is in Kentucky. We’ve had to work through where the Engineering team and Product Manager sits for the Operations Engineering team to make them both effective but also still connected to the larger Engineering and Product team.
We recently placed a Product Manager in Kentucky. Ultimately, it’s very important that we have someone on the ground in our manufacturing facility that is near to the stakeholders: the people making our frames.
Additionally, Operations works very differently. They don’t use Slack. They’re on their feet all day and use walkie-talkies as their primary form of communication.
Brock: They run an overnight shift and an early morning shift.
How do we make sure we’re not disrupting their days with changes?
If something breaks at 2AM, we have to respond or they have to send people home.
Having someone physically there has been crucial.
Catherine: We have an engineer on-site who can go and work on the technology there.
That side of our engineering has a lot to do with machine integration. Working with acrylic cutters, robots, and the different machinery we have there.
We have one Engineer on site but the rest of our Engineering team is remotely distributed. And we have our Product Manager who is on-site every day and communicates with us as the eyes and ears for the manufacturing facility.
Have you seen any folks internally on the engineering team that were interested in joining the product team or visa-versa?
Catherine:
I think product managers typically fall into one of three camps:
- They’re business-oriented.
- They’re design-oriented.
- They’re technically oriented.
I hire in that way. You have to think about the need you’re trying to fill. This is particularly true in our Operations team. They are more technically minded Product Managers, whereas someone from the Consumer team is likely going to be more design or business-oriented.
Sometimes a technically minded Product Manager has an engineering background.
That can be dangerous because if they know too much about it, you start to step on engineer’s toes and that can break down trust between product and engineering people.
Brock: One of the things that’s most important to me from a Dev Lead/Technical Lead is someone who has a product and stakeholder-oriented mindset. Someone who can both know when to trust the product manager and also has the customer in their head the whole time they’re architecting
What project management tools do you use?
Catherine: We use JIRA to manage our sprints. We use ASANA in other parts of our organization.
I’m a true believer that the best tools are ones that people will open and can access. For us that’s Google Sheets and Google Slides.
Product has product roadmaps built in Google Sheets. While we try to use Confluence and other things, Engineers are comfortable with JIRA and the rest of the organization uses Google Suite. If you want someone to look at something, put it in Google Suite.
I’ve tried many other things but keep coming back to Google.
What is your tech stack?
Brock: We use Ruby on Rails and JavaScript.
Our ecommerce experience is built on Spree Commerce. It was a popular choice in 2014 when we started. It fell off for a bit but I think it’s having a comeback.
We’ve had to build a lot of custom integrations and ripped out things that weren’t aligned to our specific use case. For example, all of our frames are custom. We don’t “sell out” but we might not have a certain material.
On the JavaScript side we were doing AngularJS, but we’re moving to VueJS. Our retail POS tool is VueJS.
We recently updated our native apps to be React Native.
It was annoying there was no good Vue Native, and React Native is so popular that it was the right answer.
We’re all AWS. We’re pretty off the shelf, trying not to go into AWS specific technology.
We’re using RDS but really it’s Postgres. We’re using ElastiCache but really it’s Redis, it’s Memcached.
As of the middle of last year, we’re orchestrating it all using Kubernetes. We’re not using EKS, we’re doing our own build with a great company called Fair Winds. They’re basically an infrastructure as a service company for us when it comes to Kubernetes.
We have dynamic staging environments. I have a command I can run that will spin up an environment on any branch I want.
I can run it internally and it runs off staging data.
We’ve also built our in-house manufacturing workflow and integration platform.
It is a monolith, with the same database as our ecommerce platform. There are some chunks of code that are pretty distinct between them, but it is ultimately a monolith.
Originally published at https://dmv.myhatchpad.com.
