Ask HN: How do you divide time between engaging with users and development?
74 comments
I really value unfiltered end user input. No third party customer contact is going to tell you that use looked for "Export" under the "File" menu instead of where you had it the very first time they used the product. You have to watch over the users shoulder of have video.
I reserve my mornings for "thinky" time. It's when I have the most energy. I answer emails in the afternoon.
This may be controversial, but I try not to respond to email immediately. I believe when you do that, the client/customer will coming to expect a quick response leading a "conversation" instead of an asynchronous email. With an email question that gets answered say, once a day, the user will endeavor to phrase his questions more thoughtfully.
I reserve my mornings for "thinky" time. It's when I have the most energy. I answer emails in the afternoon.
This may be controversial, but I try not to respond to email immediately. I believe when you do that, the client/customer will coming to expect a quick response leading a "conversation" instead of an asynchronous email. With an email question that gets answered say, once a day, the user will endeavor to phrase his questions more thoughtfully.
> I believe when you do that, the client/customer will coming to expect a quick response leading a "conversation" instead of an asynchronous email.
For me, this doesn't happen as much as I thought it would. I consistently get told how my support emails are a breath of fresh air compared to other software companies. Support emails can be an effective marketing tool. Done correctly, fast replies can definitely increase conversions or help with word-of-mouth marketing. As a one person business, doing things that don't scale is the advantage you have over other larger companies.
I don't respond to all emails immediately, especially low effort ones (or ones with dozens of questions that can be answered by using a free trial). However, I do believe there's a skill in learning how to read emails "between the lines" and determining if there's value in replying quickly.
For me, this doesn't happen as much as I thought it would. I consistently get told how my support emails are a breath of fresh air compared to other software companies. Support emails can be an effective marketing tool. Done correctly, fast replies can definitely increase conversions or help with word-of-mouth marketing. As a one person business, doing things that don't scale is the advantage you have over other larger companies.
I don't respond to all emails immediately, especially low effort ones (or ones with dozens of questions that can be answered by using a free trial). However, I do believe there's a skill in learning how to read emails "between the lines" and determining if there's value in replying quickly.
"I really value unfiltered end user input. No third party customer contact is going to tell you that the user looked for "Export" under the "File" menu instead of where you had it the very first time they used the product. You have to watch over the users shoulder of have video."
To clarify, the users first impression or actions are a one time only event that you want to capture as a developer because they won't do it the same ever again.
The analogy I use is: Suppose the carpet on the door sill of your cubical is unglued so it sticks up a little. The very first time you walk over the threshold you may trip. After that, you unconsciously lift you foot a little higher every time you go into you cubicle.
In your role as a product designer, you want to avoid "tripping" the user if at all possible. When I'm working on a GUI, I want it to be "invisible" to the user - it just works. I rarely succeed 100%, but I try. The developer who says "the user is doing it wrong" should re-access their attitude. (I've developed CAD programs, solid modelers, oscilloscopes, etc. Basically, tools for technical people.)
To clarify, the users first impression or actions are a one time only event that you want to capture as a developer because they won't do it the same ever again.
The analogy I use is: Suppose the carpet on the door sill of your cubical is unglued so it sticks up a little. The very first time you walk over the threshold you may trip. After that, you unconsciously lift you foot a little higher every time you go into you cubicle.
In your role as a product designer, you want to avoid "tripping" the user if at all possible. When I'm working on a GUI, I want it to be "invisible" to the user - it just works. I rarely succeed 100%, but I try. The developer who says "the user is doing it wrong" should re-access their attitude. (I've developed CAD programs, solid modelers, oscilloscopes, etc. Basically, tools for technical people.)
I think the amount of times the user is allowed to trip should be proportional to the intensity with which the user is going to use the tool. If the tripping enables advanced use, of course, which is not the case in your example.
First time use is completely different than prolonged use. Efficient use is not necessarily the same as ease of discovery. The first time I rode a bike, I fell off. Does that mean bikes are badly designed? I get the feeling most designers who make an effort only look at that first time use.
I get it, if the user comes around only once a month, your product should be super easy en intuitive. But if it is used daily, your product is a tool and is allowed to require skill to master. If the end result is better in some way. Either because it is more efficient, or because it takes time before one sees that there is actually more logic in that interface than you thought the first time you used it.
First time use is completely different than prolonged use. Efficient use is not necessarily the same as ease of discovery. The first time I rode a bike, I fell off. Does that mean bikes are badly designed? I get the feeling most designers who make an effort only look at that first time use.
I get it, if the user comes around only once a month, your product should be super easy en intuitive. But if it is used daily, your product is a tool and is allowed to require skill to master. If the end result is better in some way. Either because it is more efficient, or because it takes time before one sees that there is actually more logic in that interface than you thought the first time you used it.
"Falling Into the Pit of Success" by Jeff Atwood
https://blog.codinghorror.com/falling-into-the-pit-of-succes...
"I think this concept extends even farther, to applications of all kinds: big, small, web, GUIs, console applications, you name it. I've often said that a well-designed system makes it easy to do the right things and annoying (but not impossible) to do the wrong things. If we design our applications properly, our users should be inexorably drawn into the pit of success. Some may take longer than others, but they should all get there eventually.
If users aren't finding success on their own – or if they're not finding it within a reasonable amount of time – it's not their fault. It's our fault. We didn't make it easy enough for them to fall into the pit of success. Consider your project a Big Dig: your job is to constantly rearchitect your language, your API, or your application to make that pit of success ever deeper and wider."
https://blog.codinghorror.com/falling-into-the-pit-of-succes...
"I think this concept extends even farther, to applications of all kinds: big, small, web, GUIs, console applications, you name it. I've often said that a well-designed system makes it easy to do the right things and annoying (but not impossible) to do the wrong things. If we design our applications properly, our users should be inexorably drawn into the pit of success. Some may take longer than others, but they should all get there eventually.
If users aren't finding success on their own – or if they're not finding it within a reasonable amount of time – it's not their fault. It's our fault. We didn't make it easy enough for them to fall into the pit of success. Consider your project a Big Dig: your job is to constantly rearchitect your language, your API, or your application to make that pit of success ever deeper and wider."
> This may be controversial, but I try not to respond to email immediately.
Interesting approach. Personally I just cancelled a premium service because the product didn't work as expected, and getting replies to customer service took a couple days.
Interesting approach. Personally I just cancelled a premium service because the product didn't work as expected, and getting replies to customer service took a couple days.
Your emails were probably in a queue, handled by people who work on them full time. It's completely different than someone choosing to answer your email later.
I do the same. Of course, it depends on the situation. When someone is blocked, or when it's a fellow dev, I respond fast. But responding immediately often teaches people (especially non-technical ones) that you have time and focus to always reply this fast. Value your own time, and manage others' expectations. Scheduling that e-mail for 15 minutes later will save you lots of time and frustration in the long run.
I do the same. Of course, it depends on the situation. When someone is blocked, or when it's a fellow dev, I respond fast. But responding immediately often teaches people (especially non-technical ones) that you have time and focus to always reply this fast. Value your own time, and manage others' expectations. Scheduling that e-mail for 15 minutes later will save you lots of time and frustration in the long run.
> You have to watch over the users shoulder of have video.
Perfect advice. Sadly...
Perfect advice. Sadly...
Depressing actually.
I still don't understand how it works, really. I asked someone how to do something in Postman (I couldn't not immediately find it in Google); he sent me a 15 minute video. Slow, boring, not copy-pastable, etc but yeah it worked. I checked the description and the owner also wrote a blog post, which distilled the 15 minutes in 10 lines, 3 if you exclude the introduction. Vastly more effective; no idea why people prefer videos. I only do when i'm resting ; then I put on some (usually programming language) meetup/event video in the background while resting my eyes. That only helps because i'm not really doing something actionable, but when doing something actionable, reading is always faster and you can copy/paste when there are slabs of code...
I still don't understand how it works, really. I asked someone how to do something in Postman (I couldn't not immediately find it in Google); he sent me a 15 minute video. Slow, boring, not copy-pastable, etc but yeah it worked. I checked the description and the owner also wrote a blog post, which distilled the 15 minutes in 10 lines, 3 if you exclude the introduction. Vastly more effective; no idea why people prefer videos. I only do when i'm resting ; then I put on some (usually programming language) meetup/event video in the background while resting my eyes. That only helps because i'm not really doing something actionable, but when doing something actionable, reading is always faster and you can copy/paste when there are slabs of code...
I think you are getting the wrong end of the stick here. In trying to diagnose users issues a video of what they actually did is often 100 times more effective than asking them. It's analogous to having eye witness testimony compared to CCTV / body cam evidence backing up the testimony.
In a previous job we used to use some web service where they got users to test your product providing commentary on what they are doing at the same time. It was so useful that we paid an intern to go through the videos and highlight bugs and annotate the times in the videos.
I briefly considered creating a startup around similar ideas but got put off by the amount of hard work getting cross platform screen recording working would be.
In a previous job we used to use some web service where they got users to test your product providing commentary on what they are doing at the same time. It was so useful that we paid an intern to go through the videos and highlight bugs and annotate the times in the videos.
I briefly considered creating a startup around similar ideas but got put off by the amount of hard work getting cross platform screen recording working would be.
Exactly. Words cannot describe what sort of behaviors I've witnessed over the years. I.e. someone right-clicking copy-pasting 256 separate lines one by one into a text field. Normally a developer would never even consider such a scenario, given that it would take the user a good 40 minutes to do that. But there we go...
Incidentally, this happened to me yesterday. Roll20 told me that my library was full but didn't give me an obvious way to delete more than one item at a time, so I spent 40 minutes reverse engineering their API to batch delete everything I'd uploaded.
Naturally, I found the bulk delete function as soon as I had finished.
Naturally, I found the bulk delete function as soon as I had finished.
Ah! Sorry, indeed I understood the reverse; that as product owner you have to make videos to show everything by making videos.
Yep, absolutely right!
Yep, absolutely right!
Because a video captures the actual behavior, and writing is subject to what the author thinks is relevant. It might miss crucial bits of info, that cannot be left out in a video.
I remember a bug report that had the instructions meticulously written out to reproduce. Only, it didn't reproduce the issue. Luckily I also had a video, and when I watched it, it all made sense (well, why I couldn't reproduce it, the bug was ridiculous and required going through a very specific path to get the state juuuust right). You had to click the "icon" in the top left corner to eventually trigger the bug, not "go back to the app home page" via the back button like what I was doing.
My co-founder and I divide our days: before lunch, we take meetings, user interviews, feedback sessions, respond to emails, and tickets. Essentially shallow or synchronous work.
After lunch, we go heads down on coding, design, or writing work. Deep or async work.
This system allows us to always have daily feedback on our product but also uninterrupted time to change the product, every day.
You have to time-box the sync/shallow work, enough to get a good loop in but it's okay if certain things get pushed a day or so. You always have to make space for the deep work.
After lunch, we go heads down on coding, design, or writing work. Deep or async work.
This system allows us to always have daily feedback on our product but also uninterrupted time to change the product, every day.
You have to time-box the sync/shallow work, enough to get a good loop in but it's okay if certain things get pushed a day or so. You always have to make space for the deep work.
I think this is a good division but I'd switch the order. Deep work requires concentration that rapidly evaporates later in the day. This varies between people but I find I'm most successful when I put my most difficult and demanding work in the morning.
I think this might be a morning person / evening person thing. I for example find it much easier to do deep work later in the day.
I would flip this. I'm personally fresher in the morning and would dedicate that time to coding as it needs more willpower.
Interesting...what made you two decide to go heads down in the afternoon versus morning?
I am not a developer, but rather a somewhat advanced user. I constantly interact with FOSS developers, so I’ll tell you what I think from that point of view:
- I am grateful for all the voluntary effort that create wonderful programs that are a joy to use
- I understand developers have other commitments
- I understand developers have personal lives, and require rest and leisure
- I understand my requests will eventually not be met, or will take a long time to be answered
- I actually prefer that developers take their time to answer me because I care about their well being. Happy developers are also less likely to direct their frustrations at the users
- In conclusion, you should prioritize what you find more joyful and productive. Support is important, but it cannot get in the way of your happiness and mental health
Incidentally, your README reads more like an essay than an introduction. I suggest you make it more to the point, and provide a link for further explanations.
- I am grateful for all the voluntary effort that create wonderful programs that are a joy to use
- I understand developers have other commitments
- I understand developers have personal lives, and require rest and leisure
- I understand my requests will eventually not be met, or will take a long time to be answered
- I actually prefer that developers take their time to answer me because I care about their well being. Happy developers are also less likely to direct their frustrations at the users
- In conclusion, you should prioritize what you find more joyful and productive. Support is important, but it cannot get in the way of your happiness and mental health
Incidentally, your README reads more like an essay than an introduction. I suggest you make it more to the point, and provide a link for further explanations.
Unfortunately users like you are far and few between, at least it seems to me, anecdotally.
A great majority of users seem to want answers right away because they're blocked and you're the only one (sometimes) who can unblock them.
A great majority of users seem to want answers right away because they're blocked and you're the only one (sometimes) who can unblock them.
You’re probably right. But I suppose people like me don’t draw too much attention on themselves.
And the human brain tends to store and give more weight to negative experiences.
But I digress.
And the human brain tends to store and give more weight to negative experiences.
But I digress.
> Incidentally, your README reads more like an essay than an introduction. I suggest you make it more to the point, and provide a link for further explanations.
Thank you for the feedback!
Thank you for the feedback!
I have this problem. I run a small MMORPG and I'm known for being very hands-on with my community both in the game and on Discord. It's a great selling-point and I think my players really appreciate me answering all their feedback and suggestions.
It is however very time-consuming to the point where my productivity becomes zero. What has helped me is to be very transparent about this, telling them that I will need to close down Discord and focus on the new patch. They understand since everyone is always very eager for the next update.
During crunches I normally have Discord closed and only hop on once a day to go through the messages. The in-game chat is impossible to keep up with so I tend to say away from there completely between patches, which means a lot of feedback is lost but the players know this and direct newcomers to the Discord instead.
After a patch is released I dedicate a couple of days just interacting with the community both in the game and on Discord. I used to be very stressed out by all this but being transparent about my limited time and priorities has helped me a lot.
It is however very time-consuming to the point where my productivity becomes zero. What has helped me is to be very transparent about this, telling them that I will need to close down Discord and focus on the new patch. They understand since everyone is always very eager for the next update.
During crunches I normally have Discord closed and only hop on once a day to go through the messages. The in-game chat is impossible to keep up with so I tend to say away from there completely between patches, which means a lot of feedback is lost but the players know this and direct newcomers to the Discord instead.
After a patch is released I dedicate a couple of days just interacting with the community both in the game and on Discord. I used to be very stressed out by all this but being transparent about my limited time and priorities has helped me a lot.
As someone who's working on amateur game, this is super interesting to learn.
At what point did you decide it was worth setting up the discord? Early on, before you had anything to show? Based on player feedback?
At what point did you decide it was worth setting up the discord? Early on, before you had anything to show? Based on player feedback?
I've been working on the game for years and used to have a pretty big community that I only communicated with through the in-game chat. Then life got in the way and the server was down for two years which meant I lost most players (I don't require an email address so no idea who they are). I really wish I had set up the Discord much earlier so I could at least have kept a communication channel for the early adopters.
All in all the Discord server has been a major turning point in community building so I recommend setting it up and promoting it as soon as possible. I've even added a quest for new players to join the Discord server that gives some in-game rewards.
All in all the Discord server has been a major turning point in community building so I recommend setting it up and promoting it as soon as possible. I've even added a quest for new players to join the Discord server that gives some in-game rewards.
Cool, thanks for the info =)...
Sounds like when I start sharing it a bit more I'll need to budget some time to put together a discord.
Sounds like when I start sharing it a bit more I'll need to budget some time to put together a discord.
If you wanted to capture in-game feedback, you could add it to the chat. Like, /feedback or /bugreport commands. Then you could do whatever with those. Email to yourself.. Or even set up a discord bot you post them to your existing feedback channel.
That's a great idea. For next patch I'm actually making a Discord integration that will post major game events to a channel so it would be pretty trivial to set up. Thanks!
It depends on what you want to achieve. Do you want to rapidly build up a community around the project or you just want to provide some value on the long term to whoever may be interested in what you offer.
If you want the former, then you'll probably have to spend considerably more time engaging with users, and, as a developer myself, I can say that that will probably be annoying.
If you want the latter, just let things flow naturally. Periods of development and user engagement will probably alternate, as you spend time working on a new feature and presenting it to the community and gathering feedback.
You may also want to spend a small amount of time daily/weekly to just check on active user feedback.
P.S. I run and NGO and manage/develop a platform consisting of a mobile app and a site that allows users to send feedback to public institutions on various types of problems and also integrate the public info so that it is available for anyone to check out. Personally I want this to evolve organically and I spend my time as described above ( the second scenario ).
If you want the former, then you'll probably have to spend considerably more time engaging with users, and, as a developer myself, I can say that that will probably be annoying.
If you want the latter, just let things flow naturally. Periods of development and user engagement will probably alternate, as you spend time working on a new feature and presenting it to the community and gathering feedback.
You may also want to spend a small amount of time daily/weekly to just check on active user feedback.
P.S. I run and NGO and manage/develop a platform consisting of a mobile app and a site that allows users to send feedback to public institutions on various types of problems and also integrate the public info so that it is available for anyone to check out. Personally I want this to evolve organically and I spend my time as described above ( the second scenario ).
I have a few ideas that have worked for me in practice.
1. Work 12 hours (or more) per day and use your energy levels wisely. The reality is (IMO): you're simply doing a 2 man job.
I'd always start of coding, since I had the most energy then. In the evening, my brain would be beaten to a pulp and then I'd go the social route. Socially you suffer a bit because of it, but coding simply becomes impossible.
If I felt tired the whole day, then I'd be social the whole day. If I'd feel energetic the whole day, then I'd code.
2. Get another person on-board to do the social stuff.
I knew this one person who was very social and loved it. I like being social but this guy was infatuated with it. He did all the social things, so I could focus on coding.
3. Do it based on your mood
There have been days that even when I was energetic, I didn't feel like coding or I was working on a thorny coding problem. To simply get some variety in my day, I'd switch to social activities (e.g. posting in Facebook groups).
Note: I'd use Toggl for this stuff to ensure that I'd spend enough time on both.
---
Full disclosure: I like replying to HN questions (see my history), but in this particular case I'm also replying in part because I have a very sligthly related issue [1].
It's unrelated enough to warrant it's own topic. So, dear HN'er, if you're interested in this then you might like my question as well (I could really use the help).
[1, Ask HN: Diverging products: fork codebase, create config file or other option?] https://news.ycombinator.com/item?id=23562286
1. Work 12 hours (or more) per day and use your energy levels wisely. The reality is (IMO): you're simply doing a 2 man job.
I'd always start of coding, since I had the most energy then. In the evening, my brain would be beaten to a pulp and then I'd go the social route. Socially you suffer a bit because of it, but coding simply becomes impossible.
If I felt tired the whole day, then I'd be social the whole day. If I'd feel energetic the whole day, then I'd code.
2. Get another person on-board to do the social stuff.
I knew this one person who was very social and loved it. I like being social but this guy was infatuated with it. He did all the social things, so I could focus on coding.
3. Do it based on your mood
There have been days that even when I was energetic, I didn't feel like coding or I was working on a thorny coding problem. To simply get some variety in my day, I'd switch to social activities (e.g. posting in Facebook groups).
Note: I'd use Toggl for this stuff to ensure that I'd spend enough time on both.
---
Full disclosure: I like replying to HN questions (see my history), but in this particular case I'm also replying in part because I have a very sligthly related issue [1].
It's unrelated enough to warrant it's own topic. So, dear HN'er, if you're interested in this then you might like my question as well (I could really use the help).
[1, Ask HN: Diverging products: fork codebase, create config file or other option?] https://news.ycombinator.com/item?id=23562286
Check out BML, OODA Loop, Google Design Sprints, etc.
They're advocating serial processes that are basically:
1) build just a little 2) go observe what people think 3) harmonize those observations with your next build
A design sprint is a week long thing: some days are pure building, some are pure observing. But most days are a bit messy with a meeting scheduled on a build day, some bug fixing scheduled on an observe day, etc. The mess is okay, you're just following the cycle as best you can to ensure you're doing them both in a self-supportive cadence.
EDIT: adding another consideration, often you don't have a regular stream of inbound conversations, and you have to go outbound to get them. Best to do this when your first assumptions start forming around what you're building, that way, (a) the conversation is scheduled to give you feedback by the time you finish and (b) the meeting itself incentivizes you to build faster.
They're advocating serial processes that are basically:
1) build just a little 2) go observe what people think 3) harmonize those observations with your next build
A design sprint is a week long thing: some days are pure building, some are pure observing. But most days are a bit messy with a meeting scheduled on a build day, some bug fixing scheduled on an observe day, etc. The mess is okay, you're just following the cycle as best you can to ensure you're doing them both in a self-supportive cadence.
EDIT: adding another consideration, often you don't have a regular stream of inbound conversations, and you have to go outbound to get them. Best to do this when your first assumptions start forming around what you're building, that way, (a) the conversation is scheduled to give you feedback by the time you finish and (b) the meeting itself incentivizes you to build faster.
Solo founder here as well (launching my first product in a week, so keep in mind that I don't have much experience). My process looked something like this:
- Analyze market (Can this make enough money?)
- Chat with target market (Will anyone use this?)
- Build MVP as fast as possible (I didn't look for any feedback during this process.)
- Run first beta (Lasted two weeks, constant contact with customers, mixed with some bug fixing and developing some smaller features. Called all beta users with a short survey.)
- Build larger feature requests
- Run second beta (This one lasted one week, and I signed up 10x the users than the first beta. Similar interaction with customers. Goal was to discover usability issues and any obvious gaps. Called all beta users with another short survey.)
- Build larger feature requests
- Prepare for launch (Built: payment processing, beta user benefits, etc...)
- Respond to your post on Hacker News
- Launch!
This seemed to have worked well, as many of the beta users still use the product almost daily. I'd say overall, roughly half of the time was spent doing product management (user feedback, planning features, etc...) and marketing (landing pages, ads, help content, guides, etc...), and half of the time was spent doing development. I didn't put much thought into this initially, but it feels right in retrospect.
I don't use social media, so I didn't even think of that as an avenue for product feedback. This is probably a personal failing. My approach relied on building a landing page, driving traffic via ads, and then chatting directly with any users who joined our Slack. Not sure if this would work for everyone, but it worked well for me.
Unfortunately, I can't really think of a system for striking a balance between these two activities. For me, it mostly came down to starting the day by asking myself, "What is my biggest risk, and how do I reduce it?" The answer to that question increased the chance that I would move the needle during that day.
Sorry if that wasn't very helpful. I'm new to this, so it's hard to differentiate between activities that harmed productivity from activities that helped it. Either way, good luck with the grind!
- Analyze market (Can this make enough money?)
- Chat with target market (Will anyone use this?)
- Build MVP as fast as possible (I didn't look for any feedback during this process.)
- Run first beta (Lasted two weeks, constant contact with customers, mixed with some bug fixing and developing some smaller features. Called all beta users with a short survey.)
- Build larger feature requests
- Run second beta (This one lasted one week, and I signed up 10x the users than the first beta. Similar interaction with customers. Goal was to discover usability issues and any obvious gaps. Called all beta users with another short survey.)
- Build larger feature requests
- Prepare for launch (Built: payment processing, beta user benefits, etc...)
- Respond to your post on Hacker News
- Launch!
This seemed to have worked well, as many of the beta users still use the product almost daily. I'd say overall, roughly half of the time was spent doing product management (user feedback, planning features, etc...) and marketing (landing pages, ads, help content, guides, etc...), and half of the time was spent doing development. I didn't put much thought into this initially, but it feels right in retrospect.
I don't use social media, so I didn't even think of that as an avenue for product feedback. This is probably a personal failing. My approach relied on building a landing page, driving traffic via ads, and then chatting directly with any users who joined our Slack. Not sure if this would work for everyone, but it worked well for me.
Unfortunately, I can't really think of a system for striking a balance between these two activities. For me, it mostly came down to starting the day by asking myself, "What is my biggest risk, and how do I reduce it?" The answer to that question increased the chance that I would move the needle during that day.
Sorry if that wasn't very helpful. I'm new to this, so it's hard to differentiate between activities that harmed productivity from activities that helped it. Either way, good luck with the grind!
Freelancer here, so my perspective might be a bit different from all the solo founders in this thread.
Whenever I need to draw up a quote for a project of any size, I divide up the time as follows: 30% actual development, 50% communication with the client, and 20% set aside for any changes or scope creep that could come up during the project that I'm not sure can be billed separately. For repeat customers, the last item can be adjusted either up or down based on my past experience with them.
Anyway, what this means is that the amount of time I actually spend writing and testing the code rarely takes up more than 1/3 of the total hours I work & bill.
Spending half the time talking to the client might sound like a waste of time, but if you do it properly you can improve the quality and fit of the result so much that the client will gladly pay 3 times the effective hourly rate.
Whenever I need to draw up a quote for a project of any size, I divide up the time as follows: 30% actual development, 50% communication with the client, and 20% set aside for any changes or scope creep that could come up during the project that I'm not sure can be billed separately. For repeat customers, the last item can be adjusted either up or down based on my past experience with them.
Anyway, what this means is that the amount of time I actually spend writing and testing the code rarely takes up more than 1/3 of the total hours I work & bill.
Spending half the time talking to the client might sound like a waste of time, but if you do it properly you can improve the quality and fit of the result so much that the client will gladly pay 3 times the effective hourly rate.
I've been doing user interviews in the morning; it's been working quite well so far. I'm in CA and a lot of my customers are on the east coast (NYC), so waking up a little early to respond to emails, DMs, etc., has meant I ease into development around noon. I also made a Slack team for myself and users when I started the project, so if I'm in the middle of building a feature and on the fence about whether or not to build, I'll poll the Slack group for some quick feedback. IMO Slack is just low-touch enough to be background noise while code wrangling. There's been a lot of excellent use case comparison and unprompted feedback from that community as a result.
Poorly. Having to navigate between the two crush my development productivity and i think made me regress those past 3 years. I aslo use engaging with users as an excuse to forget, procrastinate the part of development i don't enjoy. I really like the people i'm working with and the project we're on, but this was not sustainable for me so i'm leaving, i will be replaced by two people, one engaging with users and able to execute small, limited task, who will have to learn our platform for at least two to three months, and a full-time developer later on.
My advice is unless you are really driven by your product: don't do both if you can afford to.
My advice is unless you are really driven by your product: don't do both if you can afford to.
I can totally relate to this. I built up a sas previously as a single person then later two person team, so I had to do both dev and sales. It's almost impossible to talk to potential clients after a serious stretch of hardcore coding. I end up spewing close to giberrish. Similarly, for me, being a more introverted technical type of person, trying to talk to clients is quite draining, and it's hard to pick up development work.
In the end we tried to split the work so I did more dev and he did more sales/business development type stuff. Where I do have to do both again I try to assign separate days. I'd like to hear how others deal with it as well
In the end we tried to split the work so I did more dev and he did more sales/business development type stuff. Where I do have to do both again I try to assign separate days. I'd like to hear how others deal with it as well
Developing with users. That is one strategy I am trying out now. But these are internal users.
There is no best way to be honest. Sometimes you just have to say, I am not here today. Or I am not here for two hours. But there can always be outside calls or meetings in between. Sometimes it is worth while to recognize the power users and learn them how to do things themselves. This will pay back eventually.
Also make sure you move enough and have time to reflect. And don't be shy to move things of your back upon others. A lot of people are willing to help.
You can follow some methodology, but in the end they are too inflexible or just not right for your situation. So oh well, just reflect day to day and you will learn the patterns.
E.g. Monday is for me meeting day. People come back from the weekend and have new ideas, so I need to talk with them and integrate it.
Wednesday is usually the day to reflect on how things go and to spew out designs and documentation.
Thursday is helping out users day, I sit with them and help them with their problems. This is very insightful. I make tickets for them and write down their problems. Sometimes we code together.
Friday is relax day, I can build a new feature and present it, people don't like to work on fridays, so I can do some hobbying.
Saturday is for deep serious work, nobody works then, so nobody is bothering you. I have Tuesday free.
But this pattern changes often. Sometimes it is just busy. You just have to ride the storm.
There is no best way to be honest. Sometimes you just have to say, I am not here today. Or I am not here for two hours. But there can always be outside calls or meetings in between. Sometimes it is worth while to recognize the power users and learn them how to do things themselves. This will pay back eventually.
Also make sure you move enough and have time to reflect. And don't be shy to move things of your back upon others. A lot of people are willing to help.
You can follow some methodology, but in the end they are too inflexible or just not right for your situation. So oh well, just reflect day to day and you will learn the patterns.
E.g. Monday is for me meeting day. People come back from the weekend and have new ideas, so I need to talk with them and integrate it.
Wednesday is usually the day to reflect on how things go and to spew out designs and documentation.
Thursday is helping out users day, I sit with them and help them with their problems. This is very insightful. I make tickets for them and write down their problems. Sometimes we code together.
Friday is relax day, I can build a new feature and present it, people don't like to work on fridays, so I can do some hobbying.
Saturday is for deep serious work, nobody works then, so nobody is bothering you. I have Tuesday free.
But this pattern changes often. Sometimes it is just busy. You just have to ride the storm.
It depends entirely on what you're building, for whom, and so on. I found quite a lot of the Agile (at least, as it is practiced) business to be unhelpful in several endeavors -- for whatever mysterious reasons administration was unable or unwilling to communicate that mockups are not full products or that the "clients" would be looking at anything but a finished product, rather like needing to have an entire house built before giving input on design.
For ETL business, I did most of my people-time up front, before any real code was written. Then came a long period of little interaction, then a period wherein a basically-complete system was displayed.
Analysis has a bit more periodic refinement.
Then you have the issue of finding users whose input is worth discarding, namely someone who might tell me, six months later, that someone else (who was not named) found something "too hard." I can't really do anything with that. Despite asking for names from this person, or to put be in touch with those with the complaints at the time, it just wouldn't happen, so this became someone to tune out.
For ETL business, I did most of my people-time up front, before any real code was written. Then came a long period of little interaction, then a period wherein a basically-complete system was displayed.
Analysis has a bit more periodic refinement.
Then you have the issue of finding users whose input is worth discarding, namely someone who might tell me, six months later, that someone else (who was not named) found something "too hard." I can't really do anything with that. Despite asking for names from this person, or to put be in touch with those with the complaints at the time, it just wouldn't happen, so this became someone to tune out.
Hey! I am in a similar boat, solo founder, recently pinned on an idea. I am building it and doing potential customer reach out. My learning and processes are as follows:
- I have attention issues, so separate day for development or engagement
- Exceptions are when potential customer replies back, will try to engage in an hour or so
- I stopped beating myself up if I do not get a lot done any day
- Context switching is very expensive for me, I account for that when I retrospect
- I am in Laos so much of my interaction is async because many possible clients are in Europe/US - a super nice thing
- Above point means I can not constantly engage on social media
- Above point means I need to find long term inbound strategies
- So I am investing in writing, documentation, relaunching product site multiple times a week - all ways to engage but indirect and inbound
- Lastly, It will take a lot of time - I have accepted this
Please don't use code blocks for points, they are unreadable
To be specific, don't indent paragraphs, and separate bullet points (paragraphs) with blank lines. https://news.ycombinator.com/formatdoc
I work on the Kurento Media Server open-source project, and the two main channels for engaging and interacting with users are a community Mailing List and the Github bugtracker. Everything is delivered by email, so that's my medium for 99% of cases.
There's however the issue of your question, time... it normally slips away while working on the actual project, so there is maybe only 1 or 2 days a week I actually can dedicate time to stop and check out the community. So my response to your question would be: in repentine bursts.
I don't feel bad for that, though. The general attitude (documented in our support page [0]) is that you can always "request" more explicit attention from the team, that's what support contracts are for. Otherwise all code is free of charge for you to use...
[0]: https://doc-kurento.readthedocs.io/en/latest/user/support.ht...
There's however the issue of your question, time... it normally slips away while working on the actual project, so there is maybe only 1 or 2 days a week I actually can dedicate time to stop and check out the community. So my response to your question would be: in repentine bursts.
I don't feel bad for that, though. The general attitude (documented in our support page [0]) is that you can always "request" more explicit attention from the team, that's what support contracts are for. Otherwise all code is free of charge for you to use...
[0]: https://doc-kurento.readthedocs.io/en/latest/user/support.ht...
> But to get feedback and develop relationships one has to constantly engage with people on social media.
Most of my "engaging with users" is via email. Social media such as YT comments in my case, can help but it's a miniscule portion of my time. It's also rarely as deep or as useful as email or voice calls.
Most of my "engaging with users" is via email. Social media such as YT comments in my case, can help but it's a miniscule portion of my time. It's also rarely as deep or as useful as email or voice calls.
For me it's email or chat (telegram/whatsapp/signal/skype); it used to be forums actually when they still 'worked'. HN/subreddits are quite good but I notice that usually (HN the least, Facebook the most) social media has engagement only when either party is trying to score points (likes/whatever), so me: 'we have a new feature!', them: 'I can build this in a weekend with react node, why would you pay for this?'. Aka not much engaging going on; advertising or whining...
My users are generally happy when I make new stuff for them.
It sounds like the people you're talking to on Facebook aren't your users at all. They're just commenting on your announcements which are showing up on their feeds for some reason.
It sounds like the people you're talking to on Facebook aren't your users at all. They're just commenting on your announcements which are showing up on their feeds for some reason.
Exactly, that's why I spend very little/no time there.
In most cases, the majority of my customer engagement is early in the process. Lots of discussion up front to inform the development. It tapers off through the iterations.
Traditional "feedback" only goes so far. Most customers don't actually know what they want. I spend the most engagement time discovering their process and pain points in order to help them figure that part out. Isolate one (or a few) customers that will regularly participate and provide high-quality feedback and focus your relationship building on them.
The feedback of the masses is more like an (unreliable) compass.
Traditional "feedback" only goes so far. Most customers don't actually know what they want. I spend the most engagement time discovering their process and pain points in order to help them figure that part out. Isolate one (or a few) customers that will regularly participate and provide high-quality feedback and focus your relationship building on them.
The feedback of the masses is more like an (unreliable) compass.
Good question and approach!
Don't avoid taking the necessary time to do what it takes to do the things that need to happen.
The pursuit of time saving methods, optimizations, or hacks is well and all - but actually putting in the time and effort it takes to do X right, repeatedly, is the type of thing many aspiring entrepreneurs avoid. It's very rare to be able to skip any rungs on the ladder, and despite all the possibilities of that technology can offer, there's no substitute for effort.
"Opportunity is missed by most people because it is dressed in overalls and looks like work." = Edison.
Don't avoid taking the necessary time to do what it takes to do the things that need to happen.
The pursuit of time saving methods, optimizations, or hacks is well and all - but actually putting in the time and effort it takes to do X right, repeatedly, is the type of thing many aspiring entrepreneurs avoid. It's very rare to be able to skip any rungs on the ladder, and despite all the possibilities of that technology can offer, there's no substitute for effort.
"Opportunity is missed by most people because it is dressed in overalls and looks like work." = Edison.
Here's what's worked for me
* Filter users, carefully choose whom to engage with. They must be needing and using what you build.
* Most of the users fit a persona so you need to engage with a subset of the type.
* Do not create anything in your product/project backlog unless it solves a problem for users of these products.
* Get features to these users as early as possible and make it easy for them to install, use, turn off or on. Ofcourse get their feedback.
I guess when users are a big part of product development process it feels natural and you get breaks where you can concentrate on development.
* Filter users, carefully choose whom to engage with. They must be needing and using what you build.
* Most of the users fit a persona so you need to engage with a subset of the type.
* Do not create anything in your product/project backlog unless it solves a problem for users of these products.
* Get features to these users as early as possible and make it easy for them to install, use, turn off or on. Ofcourse get their feedback.
I guess when users are a big part of product development process it feels natural and you get breaks where you can concentrate on development.
Have the community interact with it self and have it produce some document listing the questions and requests. When you can code no more take some time to write answers between them and publish.
If you are developing a product: at what point do you think you will bring on a UX person? And what would you want that person to do for you/your product?
that person should be in the room from the start. Design isn't just putting a pretty façade on it, designers should be part of the deep behavioral decisions from the start.
My sentiment exactly. The only acceptable situation to bring in a UX person on board after the product has already been mostly built is to clean up visual elements (consistent spacing, fixing color creep, choosing a font, etc.).
The larger-scale UX should be a consideration from the very beginning: What pages/ views are there, how do these conform to different user flows to minimize actions and intuit next steps, what information is most critical in the visual economics of a view? These questions should be answered before coding anything.
The larger-scale UX should be a consideration from the very beginning: What pages/ views are there, how do these conform to different user flows to minimize actions and intuit next steps, what information is most critical in the visual economics of a view? These questions should be answered before coding anything.
I’m with you. I would like to understand, however, how founders actually think about bringing UX people on board. How early? What scope? Etc.
Ah as like, a paid person who is there to do that one thing, you mean?
For most startups, it definitely takes a while. The "UX person" is generally one of the hats that one of the first founders needs to wear. I've been in startups where "the design guy" was third into the room after "the inventor/engineer guy" and "the money guy", but I think that's unfortunately rare.
As long as _someone_ has their eye on that ball from the start, it usually works out, and that someone who's keeping it in mind will (hopefully) be able to tell when there's a whole person's worth of job to do just on design, and be able to check if there's a whole person's worth of compensation available for it.
For most startups, it definitely takes a while. The "UX person" is generally one of the hats that one of the first founders needs to wear. I've been in startups where "the design guy" was third into the room after "the inventor/engineer guy" and "the money guy", but I think that's unfortunately rare.
As long as _someone_ has their eye on that ball from the start, it usually works out, and that someone who's keeping it in mind will (hopefully) be able to tell when there's a whole person's worth of job to do just on design, and be able to check if there's a whole person's worth of compensation available for it.
[deleted]
Go find people and ask questions - don't allow them documents. If you haven't started talking to people yet, you want unbiased information. Showing them a big write up will bias them.
Bring on a co-founder, dude. Why kill yourself with to Time sucks when you can focus on one and be more successful
Same question here! Currently I have a checklist of sites I check, then do dev work, then back to talking to users.
> Do you know what to do?
No: Engage users
Yes: Build
> Is your work done?
No: Build
Yes: Engage users
> Do people know what you have done?
No: Marketing
Yes: Engage users
No: Engage users
Yes: Build
> Is your work done?
No: Build
Yes: Engage users
> Do people know what you have done?
No: Marketing
Yes: Engage users
>> Do you know what to do?
> No: Engage users
> Yes: Build
So the task are sequential? I was trying to understand how to best do this parallelly.
> No: Engage users
> Yes: Build
So the task are sequential? I was trying to understand how to best do this parallelly.
This is what I consider to be a "plan":
> Problem definition > Product solution > Technical solution > Task breakdown > (optionally: > Estimation > Timeline)
Of course there's always some feedback loop between items in the sequence but for given scope it's a good idea to minimize it.
Or in other words: Pick a scope/feature/project, let's say proof of concept for your initiative. It seems like your problem description is robust enough so let's skip to Product solution.
It's a good investment to define everything you can define before stating actual implementation. If you still have some questions to answer then get the answers if that's possible. People have the tendency to leave the "unimportant" details for later but there's no gain in that. You have to spend the time sooner or later anyway. Better to do it sooner because sometimes the "unimportant" detail forces you to go back and rework bigger part of your solution.
Have your entities defined, user stories, UX mock-ups ready before working on technical solution.
Have a technical solution described and validated before you start implementation.
This way you mitigate the risk of being forced to go back to previous steps wasting time or being stuck with sub-optimal solutions.
So regarding the parent comment. If you know enough from the users/market research/cogitating to be reasonably sure about the next step then execute it. Once you get there it's time to continue the research with what you already have in mind.
Otherwise you risk getting stuck in an endless loop of tweaking and changing decisions without reaching tangible milestones.
> Problem definition > Product solution > Technical solution > Task breakdown > (optionally: > Estimation > Timeline)
Of course there's always some feedback loop between items in the sequence but for given scope it's a good idea to minimize it.
Or in other words: Pick a scope/feature/project, let's say proof of concept for your initiative. It seems like your problem description is robust enough so let's skip to Product solution.
It's a good investment to define everything you can define before stating actual implementation. If you still have some questions to answer then get the answers if that's possible. People have the tendency to leave the "unimportant" details for later but there's no gain in that. You have to spend the time sooner or later anyway. Better to do it sooner because sometimes the "unimportant" detail forces you to go back and rework bigger part of your solution.
Have your entities defined, user stories, UX mock-ups ready before working on technical solution.
Have a technical solution described and validated before you start implementation.
This way you mitigate the risk of being forced to go back to previous steps wasting time or being stuck with sub-optimal solutions.
So regarding the parent comment. If you know enough from the users/market research/cogitating to be reasonably sure about the next step then execute it. Once you get there it's time to continue the research with what you already have in mind.
Otherwise you risk getting stuck in an endless loop of tweaking and changing decisions without reaching tangible milestones.
It's a loop. You can loop it as frequently as you like. A big company might do this once a month, a true startup would do it every few hours.
It can be parallel if it's multithreaded. Certainly you don't expect one person to build and engage simultaneously, but quite often there is a list of think you know but aren't certain, and the product team can still engage users on those uncertain parts.
It can be parallel if it's multithreaded. Certainly you don't expect one person to build and engage simultaneously, but quite often there is a list of think you know but aren't certain, and the product team can still engage users on those uncertain parts.
Humans are bad at doing things in parallel.
There is no true parallel. It's small chunks of time, separated by interruptions and context stwiches, and interruptions and context stwiches are expensive.
Build in open source.
code in the morning do engagemet in the afternoon. review engagement notes just before bed. prioritize rest and nutrition.
Hire a social media marketer?
But to get feedback and develop relationships one has to constantly engage with people on social media. And that takes a lot of time.
So how do you divide your time between engaging with your users and at the same time work on the project? What is the best way to achieve the balance.
[0] https://bsldld.neocities.org