May 2016 Summaries

The emergence of software as an everyday thing has a profound impact on our lives, and the programming languages that create it also influence how we see, experience, and interact with the world. The English language's arbitrary numbering system makes math more difficult to learn, while other languages like Chinese provide a logical pattern that embeds math in the language itself. Programming languages can shape how designers and engineers think about software and impact how end-users use products. Simple languages like Python enable faster prototyping and design iterations, whereas complex languages like C++ or Java slow down the product cycle. The evolution of programming languages is creating a new type of Moore's Law, lowering the bar for entry into programming and allowing more people to translate their ideas into software, ultimately benefiting everyone.

Designing conversational interfaces is a complex task, but opinionated design principles can help push past the hype and create practical and usable experiences. These principles should guide clarity and reduce ambiguity in chatbot interactions. They are not mere truisms, but rather strongly-held opinions that an entire team agrees on, representing a north star for everyone to aim for. Key principles include "Don't pretend to be a human", "Keep it incredibly simple", "Respect the chat medium", "Optimise for the end user", and others, which should be applied consistently and methodically to create effective conversational interfaces that improve the end-user experience.

There's no handoff in product design because designers and engineers are not separated; instead, they work together from the start. This collaboration begins with understanding technical constraints early on to inform design decisions. Designers share rough prototypes with engineers and engage in discussions about technical feasibility, which can lead to a better product. As the product is built, designers work alongside engineers to refine their designs, ensuring a clearer perspective based on real data, technical constraints, and how the product feels. This approach requires empathy towards both users, clients, and engineers, leading to stronger designer-engineer relationships and ultimately better products.

Do you really need that meeting?` highlights the importance of evaluating the necessity of meetings in a growing company. Effective communication is key, but excessive communication can hinder success. The concept of Brooks' Law illustrates how adding people to a late software project increases its duration, and similarly, adding participants to a meeting amplifies the complexity of communication. Maintaining multiple connections requires attention and focus, which are scarce resources at startups. By asking oneself if they really need to attend a meeting, individuals can optimize their time and prioritize more critical tasks. Effective meetings require an owner, objective, and outcome, but also consider who needs to be on each page at any given time.

The Intercom team has launched their fourth book, "Intercom on Jobs-to-be-Done", which draws together valuable lessons learned from applying the Jobs-to-be-Done framework to software companies. Despite being a relatively new concept in software applications, little has been written about it until now. The book consolidates the authors' best thoughts and ideas into a resource that benefits anyone working in software, focusing on hard-learned lessons rather than prescriptive advice. It covers topics such as customer switching, product competitors, defining product scope, identifying job roles, Job Stories, and applying Jobs-to-be-Done to research for software products. The book provides a unique perspective on the application of this framework to software companies, offering insights that can improve customer experience and business outcomes.

There are four types of information that help software designers and developers understand the world around a customer, but don't help them decide what to build: contextually helpful information such as solutions, specifications, needs, and benefits. These types of feedback can be difficult to act on because they lack clear direction or measurement. In contrast, there are three types of actionable feedback that are instantly valuable to a product: jobs, outcomes, and constraints. Jobs refer to the specific tasks or activities that customers are trying to accomplish when using a product, while outcomes measure how customers value those tasks. Constraints, such as limitations on time, resources, or permission, can also be uncovered through customer interviews. To receive software feedback effectively, it's essential to practice probing for these different types of information and to prioritize understanding the context in which customers are providing feedback.