Narthur's Startups

That sounds like the perfect place to start, yeah! Or maybe checklist items within a gissue?

To be clear, that’s not clear to me! But, speaking of clarity, the problem may be that we’re so unclear on what we do need, that we’re not a great first customer for that reason. I don’t know.

1 Like

Yesterday I did more thinking about how to measure / systematize an experiment-based approach to product direction.

For a while I tried to think about how to use bayesian reasoning to quantify the magnitude of an experiment’s significance for the purpose of tracking with Beeminder. However, this seems tricky, since I’d prefer to quantify the input (the experimental design) rather than the output (the resulting observation). And from my basic understanding of bayesian reasoning, it’s much more concerned with the actual observation than the design of the experiment previous to the observation.

For example, say I asked people how excited they are about new feature X on a scale of 1 to 10. Once I have the observation (that is, the poll is finished), I think I could relatively easily use bayesian reasoning to approximate the significance of the result.

But how would I define the value of the experiment before running it? There are three properties I might consider–how many people responded, the average value of the response, and the distribution of the responses (e.g., normal, bimodal, …).

Every combination of these properties (that is, each discrete observation) would have a different significance compared against my starting hypothesis, yes? So how would I quantify the experiment’s potential significance to my hypothesis before making my observation?

If you’d like to help me think this through, I’d be very grateful. But be forewarned: my knowledge of this stuff is quite casual, so it may take some back-and-forth before I understand what you’re trying to say.

Somewhat relatedly, I was reminded of something that Dave Farley said in this episode of the podcast Ship It!. He drew the connection between the scientific method and continuous delivery. Basically the idea was that we want to assume we’re going to be wrong a significant percentage of the time and put systems in place that account for that, and then reduce the size of each deliverable as much as possible to reduce the amount of stuff we could be wrong about in each unit.

That reminded me that this is a big part of how science works–coming up with hypotheses and trying to falsify them. I think I had forgotten about the falsifying bit. Instead of thinking of hypotheses as questions, I should think of them as opinions or ideas I already tend to believe, and then look for ways to prove myself wrong.

So here is a list of things I already tend to believe in relationship to my startups that might be good candidates for attempting to falsify:

TaskRatchet

  • Splitting the tasks view into two tabs–Next and Archive–would both decrease the complexity of TaskRatchet’s code and make the app easier to use for users.
  • A recurring tasks feature would provide value to users and increase the number of tasks users create over time.
  • Integrating with additional third-party services would allow me to increase the usefulness of TaskRatchet and increase the number of tasks that users create.
  • Creating official Make.com and Zapier integrations would significantly increase the number of tasks users create.
  • Emailing users regularly, beemail-style, would be a significantly more effective way to gather feedback than my current method of posting to Twitter and the Beeminder forum.
  • More TaskRatchet users would see my UVIs if I posted them to the forum instead of to Twitter.
  • Continuing to develop and add features to TaskRatchet is likely to increase my monthly revenue to a degree that it is worth the effort.
  • Making TR more ADHD-friendly would make it easier for me to dogfood it, and also increase user engagement generally.
  • Switching to a tech stack other than full-stack TypeScript would not provide enough benefit to outweigh the associated costs (learning, development, new bugs, etc).
  • There are no good alternatives to Stripe that support my business model and would allow me to simplify my tax situation at a reasonable cost given my low revenue.
  • TaskRatchet can be a significant piece of how I support myself financially.

Narthbugz

  • Narthbugz, as currently envisioned, would not provide significant value for a small-a agile development team.
  • It would be too difficult for me to find initial customers for Narthbugz.
  • Narthbugz would not currently provide me enough value to warrant the time and effort I would need to spend in development.

I’ve tried to rework any items that started with “I should” into statements of the underlying ideas that lead me to believe that I should do this or that.

Do you have ideas on how I could challenge these opinions? Don’t worry if you agree with me on some of these points–the ultimate goal here is not to reverse my opinion. Rather it’s to put my opinions on a firmer foundation (which may at times mean reversing the opinion, but not necessarily).

3 Likes

Some thoughts

Do you really need to beemind the quality of your experiments? There is a chance that you will automatically optimize for higher design quality without Beeminder.

My intuition is that TaskRatchet can get you to support yourself 100% on a medium-term timescale, but that you will face the same customer acquisition issue as Beeminder: there are not many people who will recognize the value of your product.

If you really wanted to optimize for money, you might be better off creating a spreadsheet and adding one business-idea per day + some scoring (risk, cost, income according to different timescales).

You might find that there are business ideas out there that could get you to your goal in a relatively short timescale. The difference of revenue * risk is what you lose by sticking to TaskRatchet.

Have you considered in-app surveys? If your customers are procrastinators, they might be more than happy to take 5 minutes for your easy task :slightly_smiling_face:

1 Like

@sheik Yes, highly likely I’m overcomplicating this stuff!

I like your spreadsheet idea. I do think I’d prefer to use metrics like tasks / user, user retention, etc, rather than revenue directly, since I want to avoid making decisions that are good for short-term revenue at the expense of value to the user.

I have been thinking about in-app surveys. I added a simple feedback form to the app. But I wasn’t sure if there was a good tool for creating surveys like that that I’d like to use. I know HotJar has that as part of their functionality, but not sure I want to start using them just for that one feature.

1 Like

Ah, I see you’re a true LEAN startup follower :slightly_smiling_face:! “The value of a startup is defined by the sum of value it brings to their user”.

Maybe a database table whould be more appropriate for your use-case? With an app-native form?

E.g. you could choose to listen to long-time users; users who pay a lot; users who don’t pay that much; inconsistent users that you could fidelize…

Also, Hotjar is a cash-grab :chains::moneybag:

1 Like

As I mentioned here, I’m very thankful that @shanaqui is now handling TaskRatchet’s support inbox! I think this will be a big improvement for our users.

I’m still thinking about how to gather feedback on the site. I was thinking about using SurveyMonkey, but they don’t allow embeds unless you’re on a paid plan, which I don’t feel makes sense for us.

I guess one issue is it’s not clear to me where I should be storing these stats. Google BigQuery? Firebase? A Google Drive spreadsheet? Amplitude?

3 Likes

Have you considering storing your analytics on your existing database and pair it with a Business Intelligence tool such as Grafana, Tableau or Kibana?

Having the power to go the last mile; taking into account data that you didn’t think about in your analytic events can be powerful. E.g. how the account’s creation date influence user satisfaction? I don’t really know what’s relevant for you.

I am preaching for the PostgreSQL/TimescaleDB+Grafana stack for this reason.
In the same database, I have user data, orders, scraped data stored alongside a giant table that ingests tons of events each day.
Having the power to correlate these events with obscure data by doing simple JOINs allowed me to easily satisfy customer questions and improve montiroing. If I had stored these analytic events in a separate system, I would’ve needed to know in advance every attribute that I want to query or do costly app-level JOINs.

Otherwise, Google Sheets seems like an attracting option since you both automated analytics, unlimited storage, OK-ish scalability depending on your amount of data, and all that for free.

If you want the power of PostgreSQL+Grafana without having to do too much backend stuff, you can take a look at Supabase + Grafana Cloud; both have generous free tiers.

  • cost
  • privacy
  • familiarity/learning curve
    • ease of data import
    • ease of data analysis
  • analytic capabilities
    • integration with existing infrastructure
      • you want as many data points as possible
2 Likes

@sheik Currently TaskRatchet uses Firestore for the database, and that’s getting synced to BigQuery for data analysis. So you make a good case for throwing this stuff in Firestore or directly to BigQuery.


I have some ideas on future projects, but not ready to talk more about them quite yet.

Also thinking I definitely have been overcomplicating my decision making process, and should really just go with a simple impact / effort scorecard, plus making sure I’m gathering data and talking to users.

I haven’t been doing very well at talking to users. I need to find a way to get back to doing that consistently–requesting user interviews, scheduling them, and capturing feedback from them.

2 Likes

I’m continuing to work on recurring tasks support with the help of a friend. It’s a pretty big project, and we’ve been working on it for quite a while now. I think we could have probably broken it down into smaller chunks, but alas we did not, so it’s going to be a big release whenever it’s ready.

2 Likes

I’ve been working quite a bit on TaskRatchet auth. TaskRatchet now has two APIs running in parallel–the original Python version and a new Node version. That will be the case until the Node version can do everything the Python version has been doing, at which point I can retire the Python version.

I’d like to start having TaskRatchet use the Node API for the endpoints it has, but I can’t do that yet because the Node side uses Firebase Auth for authorization, and the Python side does not. Unfortunately migrating existing users to Firebase Auth has proved to be pretty tricky.

4 Likes

One thing I’ve been thinking about lately is that I might could categorize my startup ideas into the following categories:

  • Idea: It’s the spark of a startup. Nothing but a description of a potential product or service.
  • Research: I should be researching the market, competitors, feasibility, etc, as well as interviewing potential users.
  • MVP: I build and run the simplest version of the startup possible that will still attract at least one paying user.
  • Development: I try to develop the product into its full potential.
  • Growth: I make efforts in marketing and other growth-focused activities. Development may also continue.
  • Maintenance: I only do what is needed to maintain the product and service existing users. This might be a soft shift, where I simply don’t do further marketing and development beyond what is required to maintain the existing product. Or it could be a shift, where new signups are disabled and existing users are told to prepare for sunsetting.
  • Sunsetting: I shut down the product and open source as much of the code as possible.

Currently TaskRatchet is in the development stage. I’ve been thinking that I need to figure out a way to ensure I spend some time on the Idea, Research, and MVP stages as well, so that I always have potential new projects in the pipeline. Still thinking about how I could make sure I spend that time appropriately and consistently.

I think I’m particularly in danger of getting stuck in the development stage since I’m a programmer, so I’m always going to have ideas of how to improve a product through code, enough to keep me entirely busy on just that.

3 Likes

We’ve got TaskRatchet to the point where users are slowly being migrated to Firebase Auth. Basically we’re running Firebase Auth along side the old auth system, and whenever a user logs in we create them a Firebase Auth entry if they don’t already have one, and keep that in sync if they modify or reset their password. I would have much preferred to do a full import into Firebase Auth all at once, but unfortunately that didn’t prove practical.

I’ve been doing more thinking and learning about developer productivity and management. I talked to one of my old bosses about his philosophy of management.

Along those lines I’ve been thinking about how code review could be improved. I know personally doing code review can be very painful. But it can provide quite a bit of value. GitStream is one product doing some interesting things around improving code review workflows.

3 Likes

Yesterday and today I speedran creating this MVP:

https://focusqueue.taskratchet.com/

Basically I’ve been thinking about creating a mashup between Vitamin-R, Sunsama, and the Autofocus system. The link above is a very half-baked start on that.

What I’d like in something like Vitamin-R is the ability to connect it to Trello, Notion, GitHub, and Toggl, and have it show me tasks one-by-one without me having to decide what I’ll work on next. If something comes up that isn’t important, I would like to be able to skip it, snooze it, and/or just spend a small amount of time on it. Then I’d like to have that time synced back to Toggl, and also have the ability to beemind various metrics automatically, like number of items touched, amount of time spent on tasks, etc.

5 Likes

narthur I cannot express to you how much I am amped for Vitamin R + Sunsama!

3 Likes

Same times 1000. This looks very promising!

I like that during one of my tasks I got distracted and did something vaguely related instead, and then I was shocked back into my plan by hearing “OUT OF TIME!” :smile:

3 Likes

Oooooo I just had a thought! Getting distracted or spending far more time than justified on a task is one of my biggest problems I suspect. I could try a Do Less goal for the number of times I hear “out of time!” This might actually be really useful for me. It’d be sort of gamifying my task list too - I’d be racing that scary shouty man! :laughing:

EDIT:
Here we go: outoftime – alys – beeminder
with fine print and autodial (especially useful because I have no idea how many datapoints I’ll have to add).

3 Likes

@alys Woohoo!! Excited to hear how it goes!

I’ve been using a new Beeminder goal to commit to doing freshening on my TaskRatchet Notion backlog. I’m using Make.com to automate posting to Beeminder for that.

I’ve also decided to shift most of my dev focus from TaskRatchet to FocusQueue until I have an actual MVP–that is, something that’s valuable enough to have at least one paying customer. I expect my first step towards getting to that point is getting a Trello integration working, since that’s specifically what I would find useful.

3 Likes

Recently I used Mine to send deletion requests to many services I used in the past and no longer need. It’s been quite interesting seeing how much variation there is in how companies handle these requests. I can now say with some confidence that Beeminder handles these requests far better than probably 90% of organizations.

The worst has been that two companies so far (REI and the New York Times) responded to my request and basically said “We’re not going to delete your data because the laws where you live don’t compel us to.” Receiving these responses had me pretty frustrated and angry. Are we really going to only respect users’ privacy requests if the law forces us to?

This has got me thinking about how I handle data with TaskRatchet. After going through this stuff from a user’s perspective, I want to make sure I set up TaskRatchet to handle this kind of thing in a way that respects users’ privacy needs.

Currently I’m using three different analytics solutions–Google Analytics, Amplitude, and Highlight. In addition, I’ve been building out public metrics here:

Beeminder: tskrtcht

I think what I’d like to do is move away from using third-party analytics solutions, and instead put more weight on the anonymized public metrics stored in Beeminder plus any metrics I decide to bake out in Firebase.

I do realize that privacy is a sliding scale, and that there will always be people who think I haven’t gone far enough in that direction. For example, I’m sure there are users who would prefer that we used end-to-end encryption such that we would have zero access to the details of their commitments beyond due date and stakes. I don’t intend to go that far any time soon.

I think what I want to do is start thinking more in terms of tradeoffs. That is, any time I modify TaskRatchet in a way that results in collecting more user data and/or distributing that data to more third parties, I need to view that as a cost and make sure that the value provided to the user is enough to reasonably justify that cost.

The first step toward that is to look at the ways I’m already using user data and look for ways that I’m collecting data without a clear end-user benefit. When there are clear benefits, I should look for ways that I can reduce the amount of data and number of third parties who receive that data while still retaining most of the resulting benefit.

Aside: It would be cool to quantify this cost in terms of a budget, similar to how some projects have a performance budget they use to make sure they aren’t building a slow product. I’m not sure what that would look like, or how it would be tracked.

2 Likes

Today is my deadline for determining the success of the spin database.

My criteria for success were:

  • I’ve completed at least 2 spins per week on average.
  • The average word count of the last 25% of spins is at least 80% of the average word count of the first 25% of spins.
  • I’ve exceeded 400 new tasks in a week at least twice in the three-month period.

According to the last criterion, I did indeed succeed, as TaskRatchet users regularly created more than 200 tasks per week during the last three months of the previous year.

However, this had basically nothing to do with the spin database, since I very quickly abandoned it after creating it. The process created too much friction for me to stick with it.

In the future I’m hoping to work out a more iterative approach to this kind of thing that won’t create as much friction as the spin database did.

2 Likes