Brad Frost argues that design tools are holding us back because “they require a specific toolchain in order to function”. Instead, what we need is closer collaboration:

Tooling can help, sure, but it’s not a silver bullet. To truly address the realities of the medium for which you’re designing, designers and developers should collaborate as equals to solve problems together. That means more talking and real-time collaboration and less time spent throwing static artifacts and Zeplin links at each other.

I’m not usually a fan of posts like this, but I just couldn’t resist clicking on Pink Floyd Were Masters At Achieving Product-Market Fit. The first of seven “lessons” is the one that stands out for me:

Obtain Customer Feedback Before You Release Your Product

Musicians spend their entire youth writing songs and performing them in front of live audiences, which ensures that their initial album is validated by their fans before they enter the recording studio.

Unfortunately, successful musicians seldom have the luxury of market testing their subsequent albums. Instead of refining their material based on customer feedback, they are often lock away in a recording studio, isolated from their fans. Thus, it is no surprise that many bands suffer the sophomore jinx, in which their second album fails to achieve the success of their initial release.

Pink Floyd recorded Dark Side of the Moon after a year of writing and performing the material in front of live audiences. This audience feedback allowed the band to iteratively modify their creation.

Lesson: Avoid the sophomore jinx with your product launches by continuing to seek market validation, despite your initial success.

I guess in the interest of full disclosure, I should admit that I wrote a post like this once: A story about Miles Davis and the nature of true genius.

In 8 essential metrics for measuring product-led growth Katryna Balboni discusses a few important metrics for measuring and monitoring product-led growth (i.e., turning users into advocates so that they can they drive more acquisition and growth). Time to Value is one that seems particularly useful:

Time to value (TTV) is the amount of time it takes new users to realize your product’s value. Your goal should be to reduce time to value as much as possible-the sooner users reach their first aha moment or activation event, the better.

To do this, focus on optimizing your user onboarding experience around the key actions within your product that correlate to activation-like inviting colleagues to your platform, importing customer data, or integrating with other tools in their tech stack.

This was fun. I got to talk to the productboard team about our values and how we approach product strategy at Postmark. Here’s an excerpt from the article For Postmark, Product Excellence means enabling startups and developers to build great things:

For every feature that goes into delivery, and when considering Postmark’s product as a whole, Rian aims for customers to have two primary responses. One is: “Well that was easy.” The second is: “I don’t mind paying for this at all.”

“We want to create enough value so we’re not seen as just another app that our customers have to grudgingly pay for every month. We want to be the kind of software that we ourselves would enjoy using and paying for. I feel like that’s such a great metric: ‘I happily give you my money.’ That is the best response to a product.”

The co-founder and CEO of knowledge sharing tool Guru shares some great advice on product development in Mastering the Art of the Outcome: How Guru Turned Customer Success Into a Company Cornerstone. I especially appreciate his point on the importance of making customer success integral to the company very early on:

“Most young companies will hold off on investing in a customer success manager before they reach a certain annual recurring revenue. You’ll see founders working off of ratios, such as having one CSM for every one to two million in ARR, all while they’re furiously expanding the sales team,” he says. “If you want to stay outcome-oriented, that’s a huge mistake.”

In Nucci’s view, this approach overlooks a simple truth: When the contract is signed, your work is just beginning. “Dedicating a team to customer success lets you optimize for customer outcomes proactively,” he says. “If you neglect customer success, you’re setting yourself up to battle fires as they start, and potentially losing customers along the way. You don’t need me to tell you that’s not a great outcome.”

In The Slackification of the American Home Taylor Lorenz and Joe Pinsker look at how some households are starting to operate more like businesses:

Incorporating Trello, along with Gmail, into the Parker family’s life has been a godsend, in Tonya’s view. It streamlined family communication, helped keep everyone organized, and added a layer of accountability to tasks. Now, instead of wondering if her children forgot to do something, Parker says she can ask, “How are you doing on your checklist?”

This is a fascinating trend. I can understand the use of Trello, and maybe even Slack, but… JIRA? That seems like a lot:

Julie Berkun Fajgenbaum, a mom of three children ages 8 to 12, uses Google Calendar to manage her children’s time and Jira to keep track of home projects.

Philipp Krehl has a very thorough, practical article up on Mind the Product called Product Discovery or Product Delivery: How do you Decide? His main thesis is that figuring out when it’s safe to move to the build/delivery phase of a project is all about your level of certainty about the problem you’re solving. He proposes a simple rubric to calculate your comfort level with different product risks:

If you and your team have marked every answer a 3 or below, it confirms that you have a high degree of certainty about your path, and you can start building. You will probably still discover new information but you can just adapt to it — this is why we work with Agile methodologies like scrum or Kanban.

Answers marked with 4 or above indicate areas where you should invest and do product discovery to reduce your uncertainty. At this stage, it’s better to figure out the right thing to do rather than commit to an outcome.

Once you have identified areas which require more understanding you can use an effective technique called Assumption Mapping.

He also provides a good overview of the value and practical aspects of Assumption Mapping, a method I am keen to try out.

Shaun Juncal makes a compelling argument in Product Accessibility Shouldn’t Be an Afterthought:

But addressing accessibility early and often—if not making it an ongoing pillar of product quality—is a best practice every product team should embrace. Accessibility enables the maximum number of potential users to engage with products, increasing the total addressable market and avoiding frustrated customers from getting tripped up on accessibility shortcomings. […]

When a product doesn’t fully incorporate accessibility, the company is essentially telling a cohort of potential users that “this product isn’t for you.”

He shares some good advice on how to make accessibility efforts a natural part of the product development process.