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