The Product-Minded Engineer is someone who combines two modes of thinking:
Systems thinking Considers topics like algorithms and data structures, programming languages, fault tolerance in distributed systems, memory constraints of firmware, and so forth.
Product thinking Comprises understanding users, their background knowledge and needs, their sequences of actions, and group dynamics—plus the design techniques and information architectures that serve them.
That sounds great… it’s difficult to explain sometimes how my background in Entrepreneurship can help build better products and services for users, but it is about building products for users, based on what users want and trying to deeply understand their needs and how the business can address them and solve their problems.
The author suggests that someone armed with these skills can:
- Prioritize your efforts better based on your impact.
- Work more effectively with product managers and designers.
- Make better-informed engineering design decisions.
- Wake up most days excited to serve the people who use your product.
- Start a company as a technical founder with product sense, better able to navigate the diverse challenges that start-ups face.
- Become or improve as a tech lead, leading your teammates with sound reasoning based on user outcomes.
The loop or process for how this work is done can be shown with the Double Diamond Process Model.
These can be summarised as:
- Discover: determine who we’re serving and the problems they need solved.
- Define: architect a product that will solve those problems.
- Develop: Create the feature or product, searching for the best way to implement it.
- Deliver: Validate what you built, get it out to the customers, and collect their feedback.
The Double Diamond process can be iteratively repeated, continually getting user feedback and improving the product constantly. This is similar to Systems Thinking.
The author also notes that if you might have some frustration with a colleague, it might be because you are focusing on different phases of the Diamond process.
A good way to start designing products is to start with scenarios, such as a woman who loses her password… it might not seem very relevant when designing a Forgot Password page or the Sign Up page, but scenarios help you get in the mind of the user, and consider the overall authentication flow and how the interaction works in different scenarios.
Scenarios can also be used to:
- Show missing features.
- Help the team dream about the bigger picture and future possibilities with optimism.
- Highlight friction in the user experience.
- Validate the feature you are planning to build.
This approach of using scenarios sounds similar to personas exercises in interface design.
When exploring the user journey you need to explore these user scenarios:
- Discovery: the user has a problem and doesn’t yet know how to solve it.
- Understanding: the user encounters a feature and doesn’t know how it works.
- Usage: the user wants to employ a feature for its intended purpose while avoiding dangerous actions.
The author uses the example of Microsoft Office cleaning up and simplifying the user interface with the ribbon menu system, and also discusses that naming user elements or features is an important part of discoverability and understanding the feature, and the naming needs to make sense across a large demographic of users.
The next chapter covers errors, and it is probably the most overlooked or ignored part of designing systems and user interfaces.
In TDD, one writes the tests before the implementation. But based on what? They can’t be derived from the implementation—it doesn’t exist yet! If it did exist, it would cause implementation bias—asserting what the code does rather than what it should do.
User scenarios and dogfooding the product is one way to validate the idea before writing tests. Testing too early can also restrict how the application can change based on the exploration and user feedback in the discovery stage. Dogfooding the product and documentation can help you find and understand issues that users might encounter before the product is released. Documentation is just as important as the product, and users might go through the same stages of discovery, understanding, and usage while learning more and reading the documentation, which can trigger deeper learning and further discovery. The path from discovery to understanding is never a straight line.
Keep a Friction Log to track frustration, confusion and roadblocks while using or testing the product… That’s a great idea, similar to Failure Logging.
Rapid releases are important to allow you to quickly fix and update bugs, but also gathering metrics and tracking KPIs… basic stuff you learn in business school.
We can’t simply ask customers what they need or want. Cognitive biases interfere with our customers’ ability to answer these questions reliably. Instead, we want to listen for needs, pain points, and desires in the context of specific stories. – Teresa Torres, author of Continuous Discovery Habits
They really should have taught us more soft skills in university when studying computer science.
Failure to really understand the user’s needs and problems can result in surprises down the line, when we skip or don’t thoroughly explore the process in the discovery phase. Late stage feedback leads to delayed roadmaps and scope creep, and unhappy developers.
The key take-aways of the book so far are:
- Build the ability to gather feedback and quickly iterate
- Develop a clear picture of your target audience and what they want
- Use scenario-driven discovery to think more clearly about the little details of how customers will use your product.
- Use a north-star or vision to narrow the focus of what’s important.
- Build in systems to gather metrics and ensure the updates or changes are having a positive impact.
- Constantly ask “why?” to get to the truth of the matter.
The last chapter was just an overview of software architecture patterns.
The book was great and helped make it clear that there is a role or need out there for software engineers who can also understand business and user requirements, and see the bigger picture of what features and products should be built. A lot of these lessons are similar to what you might learn in start-up schools, about building products that people want but provided a nice explanation for each stage of the process.