5 ms·

It's amazing to me what a skill it truly is to be able to talk to customers/users, and come out of those conversations with valuable/actionable insights. As an

It's amazing to me what a skill it truly is to be able to talk to customers/users, and come out of those conversations with valuable/actionable insights. As an engineer, it's _so_ easy to fall into the traps she mentions ("not really listening to your users and [...] building something you think people want", or becoming "more focused on the excitement of the technical challenge than your users"). Until I actually tried starting a business, I always scoffed at this advice -- "obviously I won't make those mistakes!" But I still find myself goofing up over and over. It's so attractive to think that "this one new feature will make all the difference, so I should probably just focus on coding rather than talking to users." Has anyone found a particularly effective way to overcome this? Is it just a lack of discipline on my end? (Maybe I need to reread "The Mom Test" a few more times...)

cvaidya1986 6y ago
Yes, only build those things that will increase usage metrics. Get daily feedback from users and delight them with your solutions. Rinse and repeat to greatness.
csallen 6y ago
It's discipline and systems. The fewer systems you have in place to enforce correct behavior, the more you have to rely on discipline. And discipline is a tough nut crack consistently. Some of my favorite systems include: * Social accountability. The human desire to appear reliable and consistent is a power to be taken advantage of. Get a partner, a co-founder, a mentor, an investor -- someone that you have to answer to occasionally. Tell them your plans, and check in with them to review your progress regularly. In other words, set yourself up to suffer a bit of embarrassment if you don't live up to your word. * Batching. It's been said that you ship your calendar. If you think 40% of your time should be spent talking to customers, block off 40% of your calendar for that task. Don't allow yourself to write any code during that time. This is easier if you batch your work together. For example, I do this for my podcast. No coding allowed on Mon, Tue, and Wed, only podcast work. * Front-loading. I have very little willpower to make the right decision in the moment. When I'm hungry, I'll turn to junk food. So I try to pick a singular time when I'm in the right headspace to make the right decision for my future self. I grocery shop when I'm full, fill my fridge and pantry with healthy food, and rob myself of the ability to make bad choices later. You can do this with customer conversations, too. For example, on Monday schedule calls for the next two weeks. You'll be more-or-less obligated to have those calls when the date arrives no matter how you feel at the time. * Time boxing. Most of us are procrastinators. Procrastinators get the bulk of their work done just before a deadline. Use this to your advantage by setting lots of deadlines, which should ensure you have lots of productive periods. Make sure they're deadlines you can't break. I like to combine this with social accountability, meaning my deadlines are scheduled meetings or outings with other people.
- areichert 6y ago
  This is great advice -- thank you :)
macklemoreshair 6y ago
Make people pay $50 before you build it. Even if they don’t pay, you’ve tested the conversation and grounded it in an exchange of economic value.
andrei_says_ 6y ago
It’s about having to face the emotional discomfort of being wrong - in many ways, including the viability of the idea. This gets more intense the longer you’ve invested in it. It’s so much easier to sit back and tinker.
wpietri 6y ago
I think the best way to overcome that is being brutal about releasing early and often. If you are shipping to actual users every few days and then seeing how users react to the new thing, the occasional goof isn't a big deal. Indeed, it's a great way to learn some valuable humility.
- layoric 6y ago
  100%, "bias for action" as they say. Delivering something regularly and creating a loop that including customers/users etc will help form good habits. Lots of positives will flow from this I've found.
tootie 6y ago
I used a simple trick which is to fall way behind on my coding chops then take a leadership role in an org where I'm not at all familiar with the tech stack. I like to think I was a pretty sharp developer 10 years ago and now I'm practically useless. So focussing on my communication and leadership skills has been a necessity.
stickfigure 6y ago
For me it is: 1. Find the pilot customer first. Ideally more than one. Build and iterate with their guidance. 2. Do your own support. This is easy; when you're small, there's nobody else to do it. Use chat-type support apps like intercom so that every interaction is a conversation. It helps to be somewhat of a people-pleaser by nature. Just make sure you're putting your effort into pleasing the right people.
- koolhead17 6y ago
  Worked for me and happy that I am not alone. :)
Iv 6y ago
Get addicted to the feeling of clients using your stuff/loving it. It will then feel natural to want to satisfy them. Can be handy to have a salesperson slap you back into favoring paying customers/profitable niches though.
SkyPuncher 6y ago
I am very adamant about following a strong scrum cycle (although, I'm loose with the details). * Build a backlog * Run a sprint (I like 2 week sprints at startups) * Don't put anything new in the current sprint unless absolutely necessary. * Rinse and repeat The simple nature of having a "waiting" period for new features helps put perspective on them while giving you time to make sure they're broadly useful. If only a single person is asking for them, wait to build.
- ignoramous 6y ago
  > Don't put anything new in the current sprint unless absolutely necessary. As Jason Fried of 37Signals would say, "Launching something great that’s a little smaller in scope than planned is better than launching something mediocre and full of holes because you had to hit some magical time, budget, scope window." https://medium.com/@mvwi/exhaustive-notes-getting-real-37signals-ffd3990e9309 https://medium.com/@mvwi/exhaustive-notes-getting-real-37sig...
mindhash 6y ago
I have this temptation too. Its hard to juggle between programming and talking to users. There are on the opposite ends. I have been able to finish a task at least 50% of time faster just by talking to users. Now I delay the first line of code until the estimate squeezes down to a few days or a week max. Anything more and I am back to research and communication mode.

cvaidya1986 6y ago

Yes, only build those things that will increase usage metrics. Get daily feedback from users and delight them with your solutions. Rinse and repeat to greatness.

csallen 6y ago

It's discipline and systems. The fewer systems you have in place to enforce correct behavior, the more you have to rely on discipline. And discipline is a tough nut crack consistently. Some of my favorite systems include: * Social accountability. The human desire to appear reliable and consistent is a power to be taken advantage of. Get a partner, a co-founder, a mentor, an investor -- someone that you have to answer to occasionally. Tell them your plans, and check in with them to review your progress regularly. In other words, set yourself up to suffer a bit of embarrassment if you don't live up to your word. * Batching. It's been said that you ship your calendar. If you think 40% of your time should be spent talking to customers, block off 40% of your calendar for that task. Don't allow yourself to write any code during that time. This is easier if you batch your work together. For example, I do this for my podcast. No coding allowed on Mon, Tue, and Wed, only podcast work. * Front-loading. I have very little willpower to make the right decision in the moment. When I'm hungry, I'll turn to junk food. So I try to pick a singular time when I'm in the right headspace to make the right decision for my future self. I grocery shop when I'm full, fill my fridge and pantry with healthy food, and rob myself of the ability to make bad choices later. You can do this with customer conversations, too. For example, on Monday schedule calls for the next two weeks. You'll be more-or-less obligated to have those calls when the date arrives no matter how you feel at the time. * Time boxing. Most of us are procrastinators. Procrastinators get the bulk of their work done just before a deadline. Use this to your advantage by setting lots of deadlines, which should ensure you have lots of productive periods. Make sure they're deadlines you can't break. I like to combine this with social accountability, meaning my deadlines are scheduled meetings or outings with other people.

areichert 6y ago
This is great advice -- thank you :)

macklemoreshair 6y ago

Make people pay $50 before you build it. Even if they don’t pay, you’ve tested the conversation and grounded it in an exchange of economic value.

andrei_says_ 6y ago

It’s about having to face the emotional discomfort of being wrong - in many ways, including the viability of the idea. This gets more intense the longer you’ve invested in it. It’s so much easier to sit back and tinker.

wpietri 6y ago

I think the best way to overcome that is being brutal about releasing early and often. If you are shipping to actual users every few days and then seeing how users react to the new thing, the occasional goof isn't a big deal. Indeed, it's a great way to learn some valuable humility.

layoric 6y ago
100%, "bias for action" as they say. Delivering something regularly and creating a loop that including customers/users etc will help form good habits. Lots of positives will flow from this I've found.

tootie 6y ago

I used a simple trick which is to fall way behind on my coding chops then take a leadership role in an org where I'm not at all familiar with the tech stack. I like to think I was a pretty sharp developer 10 years ago and now I'm practically useless. So focussing on my communication and leadership skills has been a necessity.

stickfigure 6y ago

For me it is: 1. Find the pilot customer first. Ideally more than one. Build and iterate with their guidance. 2. Do your own support. This is easy; when you're small, there's nobody else to do it. Use chat-type support apps like intercom so that every interaction is a conversation. It helps to be somewhat of a people-pleaser by nature. Just make sure you're putting your effort into pleasing the right people.

koolhead17 6y ago
Worked for me and happy that I am not alone. :)

Iv 6y ago

Get addicted to the feeling of clients using your stuff/loving it. It will then feel natural to want to satisfy them. Can be handy to have a salesperson slap you back into favoring paying customers/profitable niches though.

SkyPuncher 6y ago

I am very adamant about following a strong scrum cycle (although, I'm loose with the details). * Build a backlog * Run a sprint (I like 2 week sprints at startups) * Don't put anything new in the current sprint unless absolutely necessary. * Rinse and repeat The simple nature of having a "waiting" period for new features helps put perspective on them while giving you time to make sure they're broadly useful. If only a single person is asking for them, wait to build.

ignoramous 6y ago
> Don't put anything new in the current sprint unless absolutely necessary. As Jason Fried of 37Signals would say, "Launching something great that’s a little smaller in scope than planned is better than launching something mediocre and full of holes because you had to hit some magical time, budget, scope window." https://medium.com/@mvwi/exhaustive-notes-getting-real-37signals-ffd3990e9309 https://medium.com/@mvwi/exhaustive-notes-getting-real-37sig...

mindhash 6y ago

I have this temptation too. Its hard to juggle between programming and talking to users. There are on the opposite ends. I have been able to finish a task at least 50% of time faster just by talking to users. Now I delay the first line of code until the estimate squeezes down to a few days or a week max. Anything more and I am back to research and communication mode.