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.

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.

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.)

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.

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."

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.

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.

Perfect advice. Sadly...

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...

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.

Naturally, I found the bulk delete function as soon as I had finished.

Yep, absolutely right!

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 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.

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.

And the human brain tends to store and give more weight to negative experiences.

But I digress.

Thank you for the feedback!

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.

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?

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.

Sounds like when I start sharing it a bit more I'll need to budget some time to put together a discord.

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 ).

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

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.

- 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!

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.

My advice is unless you are really driven by your product: don't do both if you can afford to.

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

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.

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.

  - 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

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...

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.

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.

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.

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.

* 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.

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.

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.

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

So the task are sequential? I was trying to understand how to best do this parallelly.

> 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 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.