Most teams produce it, but few know how to fight it.

In this article, I write about how to eliminate your own debt and stop producing more. This method is mainly inspired from my experience with top software engineering teams and lean manufacturing practices. You will benefit most from this article if you often find yourself struggling with too many things you’d like to fix and not enough time.

In product development, product debt typically refers to anything that either ruins the user experience or the internal productivity, and is caused by how the product is designed. …


This quick checklist helps you avoid classic mistakes when designing a new feature

Image for post
Photo by Ricardo Gomez Angel on Unsplash

Information architecture

Did you map out all the concepts, objects, structures, their properties, action they can perform or receive, and the relationships them? Have you share this modeling with your engineers? Does your design reflect the information architecture?

Stock

Did you seek how the design will impact the existing product? List the key user journeys impacted by the problem.

Real data

Did you fill your design with data from the real world? See if the data exists, and what kind of values it actually takes. Make sure the design works with 0 data or a lot of it.

Error cases

All possible error cases must be handled explicitly. What happens if the user makes a mistake? …


Do you want to start doing user research, but don’t know how? Or have you been talking to users, but got disappointing results? If yes, you are not alone.

Talking to users is one of the highest-leverage activities an organisation can invest in, but is also difficult to get right.

This is a one-stop-shop introduction to the fundamental principles behind good user research.

A rendering of a coral cup of wine on a coral background.
Photo by Mae Mu on Unsplash

Why it’s so important to get research right

You are not the user

We often assume, without realising it, that everyone thinks like we think and likes what we like. Generalising based on our own experience is actually a cognitive bias called the availability bias.

Designers and business leaders must fight this bias by interacting as much as possible with users.

People don’t tell the truth

But there is a catch. Talking to users does not automatically yield useful insights, and very often can lead in the wrong direction. Users don’t purposely lie to us, but things people say are different from things people actually do. …


“I feel great ! I have a fantastic team working with me now. […] It’s all because I have a team of A players.”

This is my summary of Who: The A method for recruiting by Geoff Smart and Randy Street.

Image for post
Photo by Josh Nuttall on Unsplash

The “A” method for recruiting

  • Make a scorecard for the position
  • Source candidates
  • Select a candidate
  • Sell the job to them

1. Scorecard

The scorecard is what you seek: the mission, the outcome and critical competencies.

The mission: An executive summary of the job purpose. = why you need to hire for this role. Example: “Double revenue over 3 years by signing large contracts with industrial customers. …


Image for post
Photo by Pineapple Supply Co. on Unsplash

Domain-Driven Design is an approach to software development based on making your software deeply reflect a real-world system or process.

“Domain” in Domain-Driven Design officially refers to a “sphere of knowledge and activity around which the application logic revolves”. In other words, the “Domain” is what is commonly referred to as “business logic” in the software world.

In Domain-Driven Design, business logic is considered to be the heart of the software.

You’ll find in this article an introduction to Domain-Driven Design that mostly follows what is explained in Eric Evans’ book. …


Image for post
Photo by Twixes on Unsplash

At Inato, all our web apps are contained in one monorepo (front-end apps, APIs, …). We use yarn workspaces to manage all of these packages.

To host and run our apps, we use Heroku.

The standard Heroku setup only works for the 1-app-1-repo use case.

So, here is a quick guide on how to host and run multiple apps from multiple yarn workspaces contained in a single Git repository on Heroku.

Disclaimer: this guide assumes a basic knowledge of Heroku (See Getting Started).

Let’s say you have a single Git repository containing multiple applications in yarn workspaces like so:

.
├── package.json
├── packages
│ ├── web-client
│ │ └── package.json
│ └── api
│ └── package.json
└── scripts
└── heroku.build …

About

Laurent Grima

https://laugri.com • Product Designer at Inato • 🥘🌱🏄‍♂️

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store