9 ms·

Ask HN: How do you divide time between engaging with users and development?

• bananamerica 6y ago
  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.
  • bsldld 6y ago
    > 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!
  • galoisgirl 6y ago
    I love you.
    • bananamerica 6y ago
      Thanks! I love you too!
  • julianlam 6y ago
    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.
    • bananamerica 6y ago
      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.
• chrisbennet 6y ago
  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.
  • axegon_ 6y ago
    > You have to watch over the users shoulder of have video. Perfect advice. Sadly...
    • tluyben2 6y ago
      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...
      • VBprogrammer 6y ago
        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.
• alyeo 6y ago
  Same question here! Currently I have a checklist of sites I check, then do dev work, then back to talking to users.
• muzani 6y ago
  > 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
  • bsldld 6y ago
    >> 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.
    • aloisdg 6y ago
      Build in open source.
    • werbel 6y ago
      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.
• AlchemistCamp 6y ago
  > 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.
  • tluyben2 6y ago
    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...
    • AlchemistCamp 6y ago
      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.
      • tluyben2 6y ago
        Exactly, that's why I spend very little/no time there.
• ackbar03 6y ago
  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
• j1elo 6y ago
  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.html https://doc-kurento.readthedocs.io/en/latest/user/support.ht...
• hopfog 6y ago
  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.
  • smichel17 6y ago
    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.
    • hopfog 6y ago
      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!
  • Folcon 6y ago
    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?
    • hopfog 6y ago
• brainless 6y ago
  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 I started full time about 60 days back. I have two startups who are interested to onboard as early adopters.
  • praveen9920 6y ago
    Please don't use code blocks for points, they are unreadable
    • mkl 6y ago
      To be specific, don't indent paragraphs, and separate bullet points (paragraphs) with blank lines. https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
• zer0gravity 6y ago
  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 ).
• orwin 6y ago
  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.
• pattrn 6y ago
  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!
• mettamage 6y ago
  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 https://news.ycombinator.com/item?id=23562286
• chasd00 6y ago
  code in the morning do engagemet in the afternoon. review engagement notes just before bed. prioritize rest and nutrition.
• deleted 6y ago
  [deleted]
• zacharycohn 6y ago
  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.
• curo 6y ago
  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.
• csteubs 6y ago
  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.
• kensavage 6y ago
  Bring on a co-founder, dude. Why kill yourself with to Time sucks when you can focus on one and be more successful
• 6510 6y ago
  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.
• kijin 6y ago
  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.
• k3fernan 6y ago
  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.
  • tschwimmer 6y ago
    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.
    • Folcon 6y ago
      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.
  • jiux 6y ago
    Interesting...what made you two decide to go heads down in the afternoon versus morning?
  • data_spy 6y ago
    I would flip this. I'm personally fresher in the morning and would dedicate that time to coding as it needs more willpower.
• at_a_remove 6y ago
  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.
• _curious_ 6y ago
  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.
• thewanisdown 6y ago
  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.
• pinopinopino 6y ago
  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.
• zabil 6y ago
  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.
• sizzle 6y ago
  Hire a social media marketer?
• meristem 6y ago
  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?
  • chadlavi 6y ago
    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.
    • meristem 6y ago
      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.
      • chadlavi 6y ago
        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.
    • ajhurliman 6y ago
      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.