Product Engineering at Assignar

Building a software application in a complex domain is not easy. At Assignar, we have multiple teams across product, platform, data, integrations, and infrastructure. The majority are product teams, who work on user-facing features. I believe a key ingredient to the success of these these teams, is product-oriented engineering, and engineers who employ this.

It has been approximately a year since I moved from Individual Contributor (IC) to Engineering Team Lead. During this time, there have been a number of challenges which we have learnt from, and can also reflect on.

What is Product engineering?#

Product engineers are hyper curious. They are passionate about the domain they work in, and they take the time to understand how it works, how the product fits in, and what its goals are. They are empathetic to the consumer, how the product makes them feel, and how they benefit from it. They can understand both product and technical tradeoffs, so a team can move faster, make better decisions, and build a better and more successful product.

Both Sherif Mansour and Gergely Orosz have described their thoughts in detail on product engineers here and here.

Product engineering is how these traits are represented by a team. Specifically how the engineers work directly with the User Experience (UX) Designer and the Product Manager (PM) across the phases of development, through the iterative discovery to delivery process.

Context is key!#

As a product team, the goal in product development is reaching concensus on the solution (or solutions) to a problem. Having the right context to make decisions as a team is a challenge. Both product and technical requirements need to be considered for a viable solution that all stakeholders are happy with. This is the 'how' to product engineering. Always working to better understand the context of the problem you are solving, and in my opinion, the hardest part.

As a team lead of a product engineering team, enabling the team to gain context is one of the most important parts of my role. Not only capturing context, but also sharing and being able to make critical decisions to move forward. This comes from process and iteration. For our team, this has a been a primary focus for learning as we have evolved over the last year.

Trust the process!#

The goal of having process is to provide opportunity to generate understanding, ask questions, provide ideas and opinion. Each team at Assignar is self-organised. This means they can work out what processes work best for their team, its members, and the features they are working on. From the perspective of my team, we are actively working on this, always iterating on how we work, trying to find what works for us as a team, and what produces a better product because of it.

The growth across the company has meant we have had the opportunity to observe and learn from other teams. By observation and cross-team collaboration, we have gained insights which may not have been highlighted by our team alone. A key takeaway from this is that teams should collaborate at every opportunity, as we have grown to be a better team with improvements to our process we would not have made otherwise.

The following is a snapshot of the processes that our product engineering team currently use to move features from ideas to released:

1. Product funnel: This is where ideas are captured and gathered. These can be from:

   • Existing/prospective customers
   • Assignar staff (product, engineers, CSMs. CEO to junior)
   • "Customer or user" research

2. Product discovery: The PM and UX research and formulate incoming features

3. Product planning: Involves UX, PM, and Engineers to update the Product roadmap

   • Forward planning: Allows the team to initialise high level requirements, opportunities, and blockers. E.g. How might this feature work with the current feature set? This involves grooming features at a high level, such mapping out deliverable milestones.
   • Estimating: Once the team has a high level context of a roadmap item, the team can give rough t-shirt size estimates (guidance for to how many sprints this may take to build). This enables the PM to better prioritise the Product backlog, and formulate user stories which engineers can groom.

4. Development discovery/definition: The engineers dig into the feature workflows and mark out questions, challenges, opportunities, and blockers. For example, the initial user stories set by Product may broken down into more granular stories, in order to increase the potential speed of deliverables. We have found that bringing together static designs and acceptance criteria into a single source can be really beneficial to processes that follow.

5. Development planning: The engineers can capture the technical context around user stories, and how they might be developed, and affect sprints. This is an extension of discovery/definition, where clear requirements and technical understanding is key capturing the right amount of context to move these stories forward.

   • Grooming: User stories are technically scoped to sub tasks, and broken down to more granular user stories where possible.
   • Story pointing: Each story is scored according to the technical requirements of the story to help guide sprint planning.

   A specific area that our team is working on here is understanding the success and failure of features. This includes capturing the right metrics, and predicting how a feature might be used. From our experience, we usually make assumptions about our users when evaluating product and technical requirement trade-offs, and that these are a good starting point.

6. Sprint planning: Plan out the incoming sprint to the capabilities of the development team per its constraints and product priorities.

7. Sprint: Development team focuses on the sprint

   • Stand-ups: Daily huddles to keep everyone updated on the status of the sprint and raise potential/found blockers.
   • Wrap-up: 2-3 days before sprint end, review board and decide if the finish line should be moved, i.e mark tickets that will and won't be started from that point. This helps drives focus for the engineers at the end of the sprint, and gives time for the PM is prepare what can/should/will be released at the end of the sprint.

8. Sprint Review: Share the results a sprint to relevant stakeholders, and reflect on the product deliverables, individual highlights, and wins for the team

9. Retrospective: Review the applied processes over the last sprint and make adjustments where required.

10. Product Reporting: Reviewing and reporting on the success of a feature once released.

The time allocation for development revolves around a 3 week sprint with a 1 week spacer for sprint planning between each sprint. Concurrently, the product discovery and planning process is run prior to any sprint starting. This should allow an appropriate amount of time and environment to enable engineers to challenge assumptions and specifications.

This may seem like a lot, and the side note here is that this is always being evaluated, where we lean in and out of certain aspects relative to the current environment. This includes factors such as team health, team velocity, sprint priorities, and team capacity and capability.

Understanding Success#

For product teams, the work isn’t complete until there is customer validation. Product engineers actively participate in planning, executing and understanding feature analytics.

Recently, with integration of multiple analytics tools to our platform, we have opened the user data flood gates. From here, we can easily go wild in answering all sorts of questions about the domain, the product, the features, and its users. However, this can be distracting and cause the team to lose focus on what the actual goals are. This is why it is important to understand what success and failure looks like. Even though success is the ultimate goal, not knowing if the feature failed to provide value, can be a bigger failure. The team won’t be able to iterate and be able to deliver a better product next time.

Some examples of how our team is trying to understand success:

1. Clearly state the user assumptions, this helps in making quicker decisions when building out the product
2. Track events and metrics that can provide meaningful data against these assumptions
3. Publish primary user events to a shared Slack channel. This can promote active discussion from real time observation of events. This is great for engineers, where active customer engagement may not be an option, so the next best option is peripheral observation.
4. Feature dashboard: centralise feature event data and customer data to answer the proposed hypothesis and questions. This is generally where success and failure are measured.
5. Domain dashboard: this is a space to analysis customer data against the domain the team is working in. This can be useful for debugging, spying edge cases, and understanding the primary use cases.

Source of Truth#

A challenge for product engineering teams is context changing. It is common for team to be working on multiple projects at the same time, all in different phases of process. Across this, multiple forms of communication are used, such as designs, documentation, tickets, message threads, and conversations. When these happen and product defining decisions are made, it is important capture these decisions at a source of truth. Depending on the decision, the source of truth may be different. When multiple sources exist, it is important to clarify what the order of priority is when sourcing product requirements. For example, when static designs are questioned and the ticket's acceptance criteria is updated with a design change, but the static design is not updated, it is important for the engineer to know the source of truth for this case.

This has been a challenge for our team, and we are actively working on how to improve how we capture information, and what engineers rely on for development. An example of this challenge was expanding from three engineers to four. We found that when two engineers were discussing a problem, we were less likely to bring the other two engineers into a discussion, compared to when it was just one. This meant that the resulting information and decisions were siloed, and without capturing it at the prioritised source of truth, it was more likely to be lost, and cause issues later in the development process.

Conclusion#

This last year as an Engineering Team Lead has been a great opportunity to learn and grow. We have built out a team of solid product-orientated engineers, evolved on how we operate, and delivered a number of valuable features. The expectation for this year will be to continue to grow the team, evolve our processes, and continue to deliver valuable product features.