What I’d Do Differently With Futurecam

I shut down Futurecam, my startup. Looking back, there are a lot of learnings, things I’d do differently next time:

⦿ I spent years working on Futurecam and its predecessor NoctaCam, and after all that effort, I realised that the market is too small, probably $10m. If I were to do Futurecam again, I’d estimate the market size before writing a line of code, and not even enter a small market, anything less than $200m.

⦿ I started Futurecam to scratch my itch, but along the way, my opinions got drowned out by those of others. So I ended up flip-flopping between building for myself and building for others. If I were to build Futurecam again, I’ll build only for myself, to begin with.

⦿ I didn’t take enough photos with NoctaCam as part of my photography, leaving aside photos I took for QA, such as analysing image quality. I didn’t take enough photos that I cared about at an artistic level. When I looked back at what I built after a year, I concluded that I wouldn’t use NoctaCam if I were not involved with the startup. If I were to do the startup again, I’ll actually use it for photos I care about at a creative, not just technical, level.

⦿ I tried to nail down the features too early, for example deciding that the product should have features like long exposure, timelapse, 30 FPS burst, etc. But I later found that some of these features were cool but did not let me take interesting photos. In fact, there were some features that none of us in the team cared about. I missed this because I did not use it in my actual photography, for shortage of time.

If I were to build Futurecam again, I’ll begin by keeping the feature set more fluid. I’ll begin by building for myself, as if we’re a services company hired by me, a photographer, to build something custom for my photography.

We’ll start with a low level of quality, a prototype quality. For example, the app may support only the most recent iPhone running only one version of iOS. The UI may not scale to different screen sizes. It may support only landscape orientation, that too only landscape right. After capturing a timelapse, the app may crash after saving it, requiring a restart before it captures again. When you grant camera permission, you may have to restart the app before it works. And so on.

The level of quality should be as low as possible, just enough for me and the team to use. This lets us iterate much faster, building features, testing them, ensuring that they lets me take interesting photos, rather than merely being cool, rejecting features that don’t. We will also explore options within a feature, such as a timer.

Iterating at a lower level of quality is faster and cheaper for the same reason that changing a blueprint of a building is faster and cheaper than tearing it after it’s built. Now, the analogy isn’t perfect — changing a building may cost 1000x as much as changing a blueprint, while changing a production-quality app that’s already live in an app store may cost only 10x as much. Still, wouldn’t you want to go 10x faster?

Even an MVP requires a looooot of work compared to an internal prototype — meeting Apple’s requirements and dealing with their rejections , UX, creating an app icon, choosing a name, permissions, supporting different models of phones and different OSs, working around Apple’s multiple bugs, handling edge cases… Anything you put on the app store is an order of magnitude more work than an internal prototype that you install on team members’ phones by plugging them in to your computer and installing locally.

Next time I’ll resist the urge to nail things down prematurely. It’s okay if it has been a long time and all we’re doing is playing around, without a plan. Being tempted to nail things down before they’re ready only makes us build features with questionable value. Committing to something that’s fundamentally questionable is a massive waste of time. It only ensures that you confront reality later rather than sooner.

When we keep the field open, we may even explore doing some things on a PC and some on the iPhone. We might have two complementary apps, the mobile app doing the capture and the PC app doing processing, designed to be used together. Or it might only be a PC app meant to post-process and enhance photos and videos captured by a mirrorless camera or SLR, with a smartphone not even in the picture. That’s what I mean by exploring different options to see what works well before committing to one.

We don’t like ambiguity. Our emotions can be valuable indicators that something is wrong, but they can also mislead us in some situations, such as making us nail things down prematurely to get a feeling of progress. But a feeling of progress is not actual progress.

I learnt a lot more in specific areas like engineering management, project management, product management, hiring, analytics and funnels

⦿ If I were to build Futurecam again, I’ll be explicit about the phases a startup goes through, like:

  1. Not validated by anyone.
  2. Validated by Kartick in his own photography (not QA).
  3. Validated by an initial set of users.
  4. Reached product-market fit.

In any stage, our job is only to get to the next stage. For example, a terrible UX is not a problem for the first 10 users — you can meet them in person and show them how it works, or do it on a video call. Start with things that don’t scale. That’s much faster than spending a quarter building a good UX. Doing the right thing at the wrong time causes failure. I didn’t appreciate that.

If I were to start Futurecam again, I’ll be clear about these stages, discuss with the team, make sure we all understand them, brainstorm, see if there are alternative stages we can come up with, commit to one, and be clear as a team.

⦿ If I were to start Futurecam again, I’ll document these stages in writing, such as a Google Doc. I found that when I tried to keep such things in my mind, my mind mixed them up, and I lost the clarity I had when I initially came up with it. So, I’ll put it in writing. Or, better, a visual, mindmap tool like Miro. Putting a tick mark next to each stage to document when I’ve reached also helps combat my natural bias as a founder.

⦿ I’m passionate about night photography, and have been taking photos like this since 2013:

In fact, part of the motivation behind starting Futurecam was to enable such photography. If I were to do Futurecam again, I’d start with just one use case — train photography at night, build a prototype, play with it for weeks or months, perfect it for this use case, stop and ask whether I’d use it, and if not, go back to square one, and repeat with a different use case. If I find I need a timer, I’d add one. If I find I’d need manual control over photography settings like ISO, I’d add it. If I found that I wanted the app to produce a great photo or video out of the box, I’d build it that way. Instead, if I wanted to maximise flexibility for editing, I’d optimise it for that.

I’d focus on depth (making it work great for one use case) over breadth (building a lot of features that are great when considered as a feature but may or may not be great for a given use case).

In other words, instead of building the app feature by feature (long exposure, then light trail, then timelapse…), I’d build it use case by use case (night train photography, then night landscape second…), always making sure that I’m doing a good job at one before moving on the next.

⦿ Early in my startup journey, I’d generate one idea, work on it, and evaluate it, but I ended up getting attached to it. It’s hard to evaluate in an unbiased way when you have only one option to depend on. So, next time I do a startup, I’ll generate multiple ideas, build them out to the least possible level of quality, and evaluate. I found that when I have multiple options, I’m doing a relative evaluation (how do these compare?) rather than an absolute one (is this good?). That makes me more unbiased, realistic and hard-nosed rather than getting carried away.

⦿ I spent significant time doing things that ultimately did not add value, like a quarter to support both landscape and portrait modes, perhaps a month to figure out how to tag photos properly with location and other attributes, and so on. Next time I do a startup, I’ll keep in mind that the most powerful tool I have is deciding not to do something. This goes back to understanding what phase the startup is in, and not doing things that are not required to get to the next stage.

⦿ When running Futurecam, I spent too much time keeping up with news about competing apps, trying them out, asking my teammembers to try them out, etc. But that wasted time and made us feel insecure more than it generated actionable ideas. So, next time, I’ll pay less attention to competitors. Paul Graham says that most startups fail due to what they did, not what competitors did.

⦿ With Futurecam, I spent a lot of effort in creating a good product, but people did not understand what it could do. Be it users or potential employees. A person I pitched to become my cofounder turned me down saying he didn’t understand what I’m trying to do. As time went by, I realised that the problem wasn’t going to go away, so I spent a person-month building a good web site. And implemented the same in-app via onboarding:

Building a great product is not enough. You need to communicate that it’s great, which can take a comparable amount of time to build a great product.

⦿ Since NoctaCam was my first startup, I was eager for advice from people who ran startups, listening keenly for the magic solution. There was none. If it were that easy, the advisors would be running the startup themselves. I had to figure things out the hard way. Over-weighting advice caused me to move in different directions, since different people were advising different things, causing me to divert from my plan, forget what my plan is, and even doubt myself. Next time I’ll be stubborn. Fast execution matters more than advice.

⦿ I started NoctaCam in 2016 which, in retrospect was too late. Virtually all my competitors had a head start. It’s better to be too early to a market than too late.

Staffing

⦿ If I were to do Futurecam again, I’ll hire a team only after I built a prototype that meets my needs personally as a photographer. Because hiring a team is a massive effort in itself, and I ended up having to do the hard parts anyway, the core image-processing parts that generate value. It would have been less effort to just do everything myself as long as the product has an audience of one: me. So that’s what I’d do next time.

⦿ Last time, I hired a backend engineer to build our iPhone app. I did this because I worked at Google, where we believed that a great engineer is a great engineer and can always learn a new framework. But in my case, the engineer took a quarter to learn iOS, at great delay and cost to me. And even after a quarter, he didn’t know all the parts of iOS that are commonly used. So, next time: 1) I’ll ignore the exaggerations about hitting the ground running. The learning curve in tech is severe — two quarters. 2) Rather than blindly following Google, I’ll do what’s right for me. 3) When I hire a backend engineer, I’d be flexible among frameworks like FaaS, Django and Rails, but I wouldn’t hire a frontend or a mobile engineer if the work is primarily going to be backend. Similarly, when I hire a frontend engineer, I’d be flexible among frameworks like Vue, React and Angular, but not hire a backend or mobile engineer if the work is primarily going to be frontend. Similarly, I wouldn’t hire a mobile engineer to build a backend or web frontend.

⦿ I worked with multiple designers over time, and all them took up too much of my time and the team’s time by insisting on re-evaluating everything from scratch that had already been discussed in great detail by multiple people. At the end of all this, they didn’t deliver enough. This is because UX design requires so much context and is tied so closely with the product vision on one hand and engineering on the other that having a separate UX designer doesn’t make sense at the early stage. Design, like product, should be done by one of the existing team members. This also reduces the N² coordination problem that arises when you have N people. If you already have 4 team members, and you decide to hire a designer, which sounds like an increase of only 25%, the time spent in coordination increases from 16 to 25, which is 56%! So, if I were to do Futurecam again, I’d design the UX myself, and hire a UI designer to pretty up each screen I’ve designed. I’d be open to feedback, of course, while being clear about roles, that I’m ultimately in charge of the design. I’d also timebox re-evaluations about things that were already discussed in exhaustive detail by others.

⦿ I asked our UX designer to design a logo, which took a lot of time. Looking back, when I calculated how much it cost by multiplying his rate by the time he spent, I was shocked to learn that it cost me a lakh rupees! And the quality wasn’t worth the price. The next time I needed a logo, I got a specialist visual designer to design one, and I got a better one for a quarter the price. So, get your logos designed by a graphic designer, not a UX designer, and work with the graphic designer as a freelancer rather than an employee.

⦿ In general, don’t work with people who already have a full-time job but want to work with you on the side, since they’ll prioritise their primary job over your work. If someone has taken up consulting as a full-time job, it’s fine.

⦿ I’ll hire a marketer in advance of the product being ready. Marketing is something that takes multiple quarters to figure out, like engineering. It isn’t something you can do on demand, like setting up a Slack account.

Administrative

⦿ I didn’t incorporate, in an attempt to reduce overhead, but it actually ended up causing more overhead. I may have lost some potential employees by communicating that I’m not serious enough to even incorporate. My accounting also became more complex, probably costing as much in chartered accountant’s fees as I saved by not incorporating, not to mention the time wasted in going off the beaten path.

⦿ When I was running my company, I didn’t have a clear sense of my personal money vs company money. I wasn’t clear whether I’m personally coming close to the red zone. To prevent these, next time I’ll plan all this out in a spreadsheet. I’ll identify clearly how much money is my personal emergency fund, not to be touched even if it means shutting down the company. And which accounts hold money meant for personal use, and which accounts or mutual funds hold money meant for company use. I’ll also be clear about liabilities like a notice period to employees. I’ll plan all this in a spreadsheet rather than mentally, because with the latter you’re never sure you accounted for everything right, so you’re never at peace.

On-demand Leader. Earlier: IIT | Google | Solopreneur | Founder | CTO | Advisor