Welcome to the bloggy home of Noah Brier. I'm the co-founder of Percolate and general internet tinkerer. This site is about media, culture, technology, and randomness. It's been around since 2004 (I'm pretty sure). Feel free to get in touch. Get in touch.

You can subscribe to this site via RSS (the humanity!) or .

Building Products

At Percolate we look for five things in product managers: Leadership, ability to get things done, communication skills, engineering knowledge, and product sense. The last is, in my ways, the toughest to interview for as part of what you’re looking for is whether or not someone has a product intuition: Do they have an innate understanding of what makes a great product? This article on how to build great products has some good things to say about where that intuition comes from and how to tune it.

On the value of talking to people:

The best way to build this intuition is to talk to a lot of people. Talk to potential users. What do they think? Talk to people who tried to build a product in your space and failed. What can you learn from their failure? Talk to competitors. How do they approach the problem? Talk to engineers in big companies. What can they tell you about the state of technology? Talk to other entrepreneurs in adjacent spaces, investors, journalists, grad students, professors, even the naysayers. The best way to get a sense of taste in a given space is to inject yourself into the industry and talk to as many people as you can.

On making sure you understand who you’re talking to and separating signal from noise:

Beware of noise. Learn the difference between your users and people who are just commenting. Everyone you talk to will have an opinion. Early on it can be tempting to design a product based on feedback from industry pundits. But a feature is only a gamechanger if the person signing the proverbial check recognizes it as one. Otherwise, it’s a distraction. Industry pundits can be extremely useful for understanding the state of your field, but they’re rarely the ones to buy your product. If you design your product around their feedback, you’ll find that there is nobody to buy it in the end.

(Further on this one is the “5 whys,” which is a Six Sigma approach that suggests asking why five times to understand the root of the challenge/opportunity to ensure that you’re solving for the right things.)

The how to build great products article also offers up a really nice framework for thinking about the different categories of features and products:

A gamechanger. People will want to buy your product because of this feature. A showstopper. People won’t buy your product if you’re missing this feature, but adding it won’t generate demand. A distraction. This feature will make no measurable impact on adoption.

Finally, I should mention that if you’re a product manager looking for a new job, you should apply to work at Percolate.

December 17, 2014 // This post is about: , , , ,

Building Products

At Percolate we look for five things in product managers: Leadership, ability to get things done, communication skills, engineering knowledge, and product sense. The last is, in my ways, the toughest to interview for as part of what you’re looking for is whether or not someone has a product intuition: Do they have an innate understanding of what makes a great product? This article on how to build great products has some good things to say about where that intuition comes from and how to tune it.

On the value of talking to people:

The best way to build this intuition is to talk to a lot of people. Talk to potential users. What do they think? Talk to people who tried to build a product in your space and failed. What can you learn from their failure? Talk to competitors. How do they approach the problem? Talk to engineers in big companies. What can they tell you about the state of technology? Talk to other entrepreneurs in adjacent spaces, investors, journalists, grad students, professors, even the naysayers. The best way to get a sense of taste in a given space is to inject yourself into the industry and talk to as many people as you can.

On making sure you understand who you’re talking to and separating signal from noise:

Beware of noise. Learn the difference between your users and people who are just commenting. Everyone you talk to will have an opinion. Early on it can be tempting to design a product based on feedback from industry pundits. But a feature is only a gamechanger if the person signing the proverbial check recognizes it as one. Otherwise, it’s a distraction. Industry pundits can be extremely useful for understanding the state of your field, but they’re rarely the ones to buy your product. If you design your product around their feedback, you’ll find that there is nobody to buy it in the end.

(Further on this one is the “5 whys,” which is a Six Sigma approach that suggests asking why five times to understand the root of the challenge/opportunity to ensure that you’re solving for the right things.)

The how to build great products article also offers up a really nice framework for thinking about the different categories of features and products:

A gamechanger. People will want to buy your product because of this feature. A showstopper. People won’t buy your product if you’re missing this feature, but adding it won’t generate demand. A distraction. This feature will make no measurable impact on adoption.

Finally, I should mention that if you’re a product manager looking for a new job, you should apply to work at Percolate.

December 17, 2014 // This post is about: , , , ,

Tools over Process

I spend a lot of time thinking about building products (and, more specifically, building teams to build products). With that in mind I really enjoyed this rc3.org post about the seven signs of a dysfunctional engineering team, especially this bit about building tools instead of process:

Preference for process over tools. As engineering teams grow, there are many approaches to coordinating people’s work. Most of them are some combination of process and tools. Git is a tool that enables multiple people to work on the same code base efficiently (most of the time). A team may also design a process around Git — avoiding the use of remote branches, only pushing code that’s ready to deploy to the master branch, or requiring people to use local branches for all of their development. Healthy teams generally try to address their scaling problems with tools, not additional process. Processes are hard to turn into habits, hard to teach to new team members, and often evolve too slowly to keep pace with changing circumstances. Ask your interviewers what their release cycle is like. Ask them how many standing meetings they attend. Look at the company’s job listings, are they hiring a scrum master?

One of the thing I try to communicate to the whole company is that it’s everyone’s responsibility to build products. Products are reusable and scalable assets. While process is a product, tools are (almost always) better. I am working on a long and sprawling explanation of all my product thinking stuff, but that will have to wait for another day.

July 30, 2013 // This post is about: , , , ,

Building Products

I promise I’ll get back to blogging more non-Percolate things, but here’s one more item. Over at the Percolate blog I wrote up a quick description of how our product development process has changed since we moved to running everything off an API:

We start by sketching everything out and finalizing flows. Once that happens everyone gets to work: Backend writes some Python, frontend writes some javascript and design finalizes interaction and visual design. Because it’s all just data being passed around, no one needs to wait for anyone else. As long as the data is modeled, we can write all the frontend code before the actual endpoints are complete (and before the visuals are solidified).

Running a product team has been a really interesting shift in career for me. Some of the stuff I learned working at agencies has been a huge benefit (working in teams, managing creative people) and some other stuff has been totally new (continually improving something instead of launching and jumping to the next thing). It’s fun to work on improving the process and flow and when you land in a real rhythm it’s pretty amazing (not that different than being in the excitement and madness of a great pitch).

I need to write up a longer thing about my overall experience, but this was a start. I’ve got a goal to write more process posts over at the Percolate blog because people seem to like them, so hopefully there’s more coming soon.

January 25, 2012 // This post is about: , ,