14 product pitfalls for startup developers like myself

Background

At some point I became obsessed with optimising my behaviour. Whether you refer to building a routine, rituals, goals, habits, systems or think of rationality, behavioural change, CBT or journaling, the direction is the same — the desire to bring about positive behavioural change. It’s no surprise then one of my favourite things in the world is to see visible progress in oneself after practising some skill, ability, or work.

After a number of years of reading and practising, failing and succeeding, I thought I knew enough about the systems and beliefs required for positive behavioural change, in not just myself, but others too.

So like any good software developer, I thought — I can build an app for this, create my own product, and have a chance at creating my own self-sustaining job which improves peoples lives.

What follows are some of the biggest mistakes I’ve made so far in trying to do so.

Let me start with the acknowledgement that all the advice you ever read will be wrong if applied to the wrong context. These lessons are generally applicable when building software products, but there will be situations where they don’t apply.

(Although don’t kid yourself into believing your product is an exception, unless you 100% know better without any doubt in the world)

Pitfalls

You have a problem, you think a solution for you might also be a solution for others.

While it’s commonly advised to scratch your own itch in product creation, giving this adage any more than just a passing thought is dangerously over-simplifying.

Creating a product is likely to take hundreds or thousands of hours.

If you spend all that time making something only for you, you’re likely making art, not a product. Making art is great, but not if you’re trying to make a product — you won’t be able to sell it as such.

Selling something to others successfully, requires it to be useful for them, and for that to be true, it needs to be made with OTHERS IN MIND — not speculative others, not generalised others. We are not mind readers as much as we like to think we sometimes are. You need real, voice of customer, surveyed / interviewed answers to know how people think.

I can’t stress this enough, I thought I knew enough about my problem domain to create an MVP and get feedback. But the MVP grew arms and legs, morphed and diverged, and then only when it became time to showcase on the landing page, did I realise I had no way of selling it as a solution. I didn’t have enough information about the problem in peoples own words for it to be meaningful to them.

Solution: Don’t start large amounts of work to scratch your own itch before interviewing other people to see how their problems align or differ.

Well, my cave wasn’t completely shut off from the outside world, and I wasn’t completely ignorant — I knew it was important to get some feedback and to talk to others about the idea, but there’s hidden potential for unsuspecting self sabotage here too.

I even started with a small survey, but my initial surveys and ‘interviews’ failed from the same two big mistakes. 1. being overly directive, and 2. Friends.

Product Pitfall: Feedback

You explain your idea to people you know and get their feedback

People you know will find it very hard to give you critical feedback, very hard to remove their biases of knowing you and will generally seek to avoid even the slightest bit of social confrontation by voicing their opinion against you.

Furthermore, even if they wanted to judge your idea without pleasantries, they see more than the product — They see you and your passion, even more true at an early stage without the product in front of them.

Solution: Pay people you don’t know on upwork, fiver or mechanical turk $5 each to interview them. Reach out to people you don’t know in other online communities.

Product Pitfall: Feedback

You explain your idea for feedback

People will ask you what you’re doing and you’ll undoubtedly have to explain your product idea, but don’t be misguided in mistaking their enthusiasm in you and your explanation, for their support of the solution and it’s applicability to them, or any kind of product/customer validation. If you’re explaining your product idea, you’re not gathering very useful information.

A reaction to your explained product idea especially by someone you know, is often just social pleasantries like ‘I’m fine thanks.’

When your goal truly to learn more about how your product might be received by others and how to make your product a success (this should be your goal!). You’ll need to conduct unbiased user interviews.

User interviews are about listening, not explaining. As such you will need to part with the subconscious desire to pitch, convince and demonstrate.

Suspend any initial assumptions, pretend you haven’t thought about your subject domain much, and engage in listening and curiosity.

Only after you have gathered all the unbiased info first, can you perhaps explain prospective product features in the context of their problems and ASK whether the feature might help.

Don’t try and do any convincing, just listen, note and ask why, probe deeper and find out more, note well their objections.

Every time you try and explain or justify, you’re loosing out on the possibility of finding real experiences and concerns to drive your product and your marketing.

Solution: Conduct unbiased interviews. Ask the person about their problems, what troubles they have in your domain, what they do about solving it, what resources they currently turn to, etc. Resist any urges to justify, just be curious.

Product Pitfall: Tech & Feedback

You don’t know many people in your target audience, so you build first to attract them with your product

If you don’t know anyone who fits your target user demographic enough to give you useful interviews, feedback or validation, it’s a good idea to find these people first, before you start building the product, because you WILL need their opinions before, during, and after building the product.

You don’t need a huge audience, but you do need some people, and building with them will be so much easier and more effective than without them.

Solution: Start with a minimal viable audience. Develop through curation, writing, sharing, webinars, existing communities, build something tiny, or other means to develop one

There aren’t many other entrepreneurial tech enthusiasts in my local professional circle, especially since doing a lot of remote work from my small town, and I’ve also had no success in the past when mixing up friends and co-founders. So I could just do this alone right?

Product Pitfall: Working Alone

You don’t have any potential co-founders, so you go at it alone.

Perhaps it COULD be possible to do it alone…

If the world stood still for years while you worked and learned. If you have a big enough community of people helping you in business, in life, funding and with sanity. If you have sufficient capital to buy the help of other experts at the times where you will need them.

…Even so, SHOULD you do it alone?

Involving yourself in all the complexity and depth of focus required to start a (product) business can be an isolating endeavor in any event, worst of all on your own.

Being my own manager at times has also been as detrimental as it is liberating. Even once you know what your primary task should be, there’s a lack of accountability to work on it. Especially with a developer focused mind, It can be easy to get distracted and work on what might be a brilliant breakthrough feature, over the less glamorous and planned work.

Also, When there’s a 100 things to be done, every time you do a high level review, check you’re working on the right thing and form a strategy, all other work stops. This was a source of great haste and frustration for me at times, and fuel for the bad habit of just wanting to ship.

Could you do all this alone?

• Code the main business logic of your product, but also: the user accounts, payment processing, data export, account deletion, packaging the app for release, debug, tests, managing upgrades, collecting metrics, and logging.
• All the interface design, graphics, user testing
• Front end, back end, the API.
• Sales and marketing is 50%, who’s going to do that?
• What about the business incorporation, bank accounts, tax filing, investment pitch deck, emails, calls, and managing relationships?
• What about the social media, inbound marketing, outbound marketing, copy writing, screen shots for each release with relevant mock data, the landing page, growing a community?
• Could you do all those things, and still have enough time remaining to plan the product and talk to users?
• Should you?

Solution: Not Sure. Possibly: Seek out teammates online/in person and conduct tiny trial projects with them to validate working together and sign founders agreements. Work in various on-prem gigs. Move to a bigger city with more people. Go to hackathons.

I thought — I can design this, I have impeccable taste, I use apps all the time, I know what I like and what I think looks good.

Product Pitfall: Design

You’re not a designer, but you know what good apps look like, you’ll just reverse engineer your own

So armed with a collage of other well designed apps, I tried to emulate what I liked.

Nothing looked good together.

Imagine trying to develop a program using only functions written by other people found on stackoverflow. Classes, files, modules — all using only pre-made functions from other people? would this work? No!

Not surprisingly I couldn’t just mash together other elements from other well thought out recipes into my own dish.

So why did I have the naivety to think I could one-up the visual arts by doing so.

I had previously only ever been seeing the finished product. I was missing was the fundamental precursor knowledge to be able to make sense of designs and adapt them.

E.g. Universal principles of design, how to properly use colour and typography, how to use whitespace and gestalt grouping, visual hierarchy, subtleties of contrast, etc.

Solution: 1. Stick to a premade design system for the first few iterations, (buy one from setproduct.com or ui8.com) or 2. Seek to understand some first principles of design, Design For Hackers / Refactorig UI have good resources on this.

Product Pitfall: Design

You want the product to look really good and have it’s own visual identity

I spent too much time trying to pre-maturely optimise the UI and UX before the product features were well validated and tested.

Every pretty thing designed that is changed before it ships is a waste of time. This goes for both visuals and interactions.

Solution: Invest time into eye candy only after product fit, as painful as a generic looking app is to your grand vision, it should be accepted as part of the process.

Product Pitfall: Design

You think hiring a freelance designer might help

I saw a recently graduated student’s work that I liked on dribbble and commissioned them to make me some sketch designs. The designs looked good after a lot of direction.

But upon trying to iterate with them myself, I found there was no UX consideration — it was purely graphic design. It didn’t work as a design system. so I couldn’t use these elements to adapt to the rest of my functionality requirements or as the features changed.

In hindsight, the wireframes I gave the designer had not been prototyped with real users against the desired goal either.

Solution: Don’t invest in look and feel until you have A) Validated the product features with a generic design first, and B) prototyping the user experience as a whole

Product Pitfall: Tech

You think a potentially complicated piece of technology is required based on assumed requirements.

Again, this goes back to the mother of all product sins which is building something large without enough user feedback. but just to illustrate how costly this can be when building for your own problem.

I thought the ability to save data while offline was crucial. Since when I wake up and meditate, I want to log my practice without turning off flight.

This personal ‘nice to have’ masqueraded as a requirement, coupled with my adamant belief that conversational interfaces are the future of digital interaction, led me down a costly path of unnecessarily complicated feature work before it was needed.

None of the popular conversation platforms enabled offline mobile use (for Flutter). So I built one.

I built a state machine powered conversational interface. With text input regex matching and suggestion options. Also building a JSON outputting, web-based conversation designer so I could reason about the conversation flow visually and export that to code.

I built this tool far too prematurely.

Did anyone else care about offline usage? NO! Not a single user who has tried the app has mentioned anything about it. Is online-only an acceptable limitation before achieving product-market fit? YES.

Solution: Validate your assumptions before building anything, validate extra well anything complicated. I say estimate your feature build time, and before you build it, spend up to 1/3 of that time with customers and prototypes making sure you’re building the right thing.

Solution: Start with the most simple thing first, asses and develop after feedback

Product Pitfall: Tech

The 3rd party library or service doesn’t do exactly what you want, so instead of adapting your requirements, you build your own.

I dismissed Google Assistant / Dialogflow initially because it didn’t have notifications, and I thought these was crucial for my app.

But.. Google have like over 50 smart engineers developing it and I’m one person dedicating only a portion of my time to my chat engine. Guess what, vendor software improves, especially backed by big companies. Google introduced notifications about 6 Months after I started building.

Solution: If a solution is complicated, and there is a 3rd party offering that does most of the work, use the parts that work while you improve your product market fit and only if there are user complaints, severe limitations, and the vendor won’t improve, then build your own.

Solution: Start with the most simple thing first, asses and develop after feedback

Product Pitfall: Tech

Designing and prototyping have gone on long enough, there’s no code, nothing for people to use yet! You decide to code something rough and iterate along the way

I have found it far to easy to get frustrated that the design & product iteration was too slow progress and that if I got coding, then that would be progress.

CODING THE WRONG THING IS NOT PROGRESS.

How do you not code the wrong thing? Validate assumptions, validate features, low fidelity prototypes, more feedback, iterate, medium fidelity prototypes, more feedback feedback, prototypes, code without a focus on design, validate functionality, then add the polish.

Every skipped step of prototyping and validating brings you more quickly towards developing and releasing the wrong thing.

Solution: If you want to code, do a side project or coding challenge, if you want to build a product: Design first, in the medium of fastest iteration you possibly can — pen and paper or monochrome wireframe kits. Validate assumptions. Show users, observe.

Product Pitfall: Tech

It’s just me [or maybe a few others] working on this, we don’t need explicit documented requirements

I’ve learnt it’s best to describe your tasks in enough detail so that someone else could do them. This avoids you adapting the task on the spot, possibly falling into the trap of iterating in code — a time expensive medium. It’s also especially important when refactoring code and services, in order to keep a handle on what will change, why and how far through it you are.

Solution: What is the main user objective? is this feature correct for that? What have you done to validate those assumptions? If you’re struggling to document the task, what information might you be missing, how might you find it, who can help?

Product Pitfall: Tech

“This is a great time to learn a new framework/language, my product might not be as great as I want it to be if I only use my prior experience”

This one is a commonly advised against pitfall, but the temptation is so strong.

I chose to develop in Google’s new cross platform framework Flutter, being unimpressed with React Native performance, but it’s immaturity a year ago and my unfamiliarity at the time has probably cost me at least a month in development time. Although I’m now a Flutter expert (and open for consulting work), It might be good for my development career but the time lost learning was not good for my business.

(Flutter articles and open-source libraries to be released soon)

So many of the most popular apps run traditional and boring stacks, again, don’t confuse being a software artist wielding cool tools with creating a useful product. Your users don’t care.

To learn a new language or framework, build incrementally complicated side projects with it, don’t rely on it for your product, it’s very likely to cause pain.

Solution: Use your most known tech stack to develop your product. New frameworks and tools are for side projects.

Fundraising without a leg to stand on

Your two fundraising legs are: Product Traction and your Personal Network. If you don’t have at least one real leg and one prosthetic leg you won’t be able to run this race. No amount of business plan or good pitching will get you very far without them.

Personal network is largely comprised of who will vouch for you and your team based on past shared interactions. (There may be proxies for this personal interaction,based on the strength of your team’s past stereotypical successes like if you’ve worked for big corps, had positive press, or graduated from esteemed institutions, or have past startup success.)

Upon realising that It was unlikely I could do this idea justice by working on my own, and not knowing any co-founders to help, I pitched for resources to form a team.

I spent two months Fundraising and probably spent cumulative weeks on various YC and other accelerator applications.

The only verbal commitment to capital I received was from a CEO of a company I used to work at, who knew me and my work enough to bet behind it. (and even this was subject to finding the other 50% from another investor)

It’s true investors invest as much in you as your business, in the early stages, it’s hard for them to validate you unless you have had past interactions with them.

Due to doing a lot of remote work from my small town, where people with capital are largely brick and mortar orientated, I didn’t personally know many others with the capital to bet on my success.

Some of the potential angels who were open to the idea and the business, told me straight up, they don’t invest in anyone they don’t know personally.

N.B. (I chose not to follow some leads who didn’t have reasonable tech-business expectations of equity and capital, or would be unlikely to contribute to the success of the business with more than just money — i.e. smart money over dumb money. I also didn’t want to mix friends, family and business in a scrounge round. I struggle enough to detach my self-worth from my work as it is.)

Solution: Don’t spend time fundraising without either strong product traction or a strong personal network, ideally both.

Mistakes Summary

Allot of these lessons are not new information to me, I’d read about them, but as always, the map is not the territory.

Especially as a developer, I thought I could take a lot of shortcuts, by just building, and figuring it out along the way and iterating quickly. I’m now of the opinion that any development done before careful, validated, planning will be 1) too slow to iterate with, and 2) run the risk of shining a shit / polishing a turd (making improvements on something that isn’t right to begin with).

I should have started with at least 100, qualified people, interested in self-development and interested in beta-testing. I should have interviewed all of them to increase my awareness of the wider problems to solve for. I should have asked for their feedback regularly.

Since not having this community at the start, it should have been my first task to find them, and not think I could delay that community/audience/customer building until later.

It takes a certain amount of humility and confidence to interview people for your product when it doesn’t exist yet. I shied away from that previously and now know the cost.

Eventually, I did start reaching out without hesitation to people I didn’t yet know, and it was only then that I received some really useful criticism and could start some conversations and uncover real people’s thoughts.

All that took was a few days of emails, posts and a landing page with screenshots of the app. I received really influential criticism.
WITHOUT ANYONE USING THE APP.

I think it’s a great exercise to start from reverse in that sense — have enough conversations and do enough research to develop your product idea up to the point of making a landing page and doing 0 coding on the idea. Get at least 100 conversations/interested people form that and asses the feedback.

I also suffered from a lot of sunk-cost and planning fallacy here, as I learned these lessons, I could have stopped developing the app at any point and changed my strategy. But I kept thinking, “just another couple of weeks and the app will be ready, then I can show people the full app for their feedback rather than just the concept!”

But those weeks go on for months and people do buy the concept as much as the app.

Idea Autopsy

I wanted to make a virtual life-coach; a ‘habit-tracker’ that personally engages with you to help diagnose your struggles when it comes to what you want to practice and improve at in life.

My working theory was that there are some universally applicable, mental constructs and exercises that can enact positive behavioural change. We just need to be taught them and to pair them with action.

Although we consume information and may often times know what we should do, that’s not the same as doing it.

I thought, if explained by conversation, prompts and questioning, that we could be more compelled to pair this wisdom with the actions required to empower our practices.

I didn’t dismiss professional human coaches as a lesser option, but not everyone can afford to hire experts to coach them through improving each specialised interest in their lives.

So wouldn’t a wise and motivating, digital life-assistant be great?

Sure, maybe, if it understood life.

The tools powering ‘conversational’ interfaces are simply not up to the task yet.

The best A.I. powered conversational tools still revolve around classifying a user’s ‘intent’ which allow us to speak commands and have our digital assistants perform actions. With enough layering of contexts, dynamic responses and functions, we can at best approach something that feels like a rigid conversation.

Suppose the technological tools and primitives were adequate enough to build richer, topical, contextual, personalised conversations. Or we put in enough work to make it feel acceptably fluid, some of the time.

A human sized hole (in digital conversations)

We’re still left with a human sized hole in the solution.

(Hat tip to Michail Rybakov who replied to my cold email for feedback and stirred my rumination on this)

A virtual coach is extremely prone to falling into uncanny valley.

Michail mentioned to me even the best case virtual interaction is missing that moment of ‘shared attention’.

I realise from this that there’s an intriguingly special quality, a kind of magic, in human-human communication that is essential to the coaching process.

The effectiveness of a human coach rests not solely on their wisdom, questions and phrases that prompt reflection but on their shared human experience and that shared moment of attention.

Direct human communication involves all kinds of social triggers. For example: wanting to feel esteemed and validated by others, resistance to social deviance, social conformance, wanting to please, obeying, feeling you’re not alone, not dismissing out of politeness, avoidance of social confrontation, etc.

The combination of one’s presence and their words, combined with all the evolutionary social conditioning we’ve had — take us out of our own world and into this shared reality of expectations. These words from another human, presented in the right way for the right person, blur the lines between motivational speaking, persuasion and hypnosis. They the power to direct our minds through trancendetory shifts in awareness.

We’re a long way off from ( the scary thought of) a machine being able to do this effectively.

Digital ‘conversations’ lack so much of what makes human conversation effective, and there are little to none, technological solutions to this problem when effective conversation is needed.

We want information but we need action

I thought if I gave someone enough tools and prompts for action, that they would. I appear to have under-estimated the resistance we can have to action.

I think it’s better to first provide people with what they want, information, and then nudge them into action.

I’ve also seen this in conversion marketing, we WANT a Tesla, we NEED to pay our utility bills. How can you make someone feel like your solution satisfies both a need, and a want.

We need help being social

With the feeling of loneliness and isolation on the rise, and many social apps substituting time in person for screen time. We need more help in facilitating presence and connections.

While I never sought to reward screen time, I feel I had neglected to sufficiently emphasise the community. My initial naive implementation of searching and joining for interest groups and sharing your progress, doesn’t sufficiently encourage what people already enjoy from in-person interest/activity groups.

My new product development oaths

I do solemnly swear to:

• Not start product development without a minimal viable audience
• Start product development by investigating and interviewing the problems that unbiased people have.
• Interview users with curiosity and not attempt to justify.
• Sell the concept first and only then develop the product.
• Try the simple solution first.
• Be quick to observe when sunk costs are keeping from changing course.
• Make product decisions not via speculation, generalisation or attempts and mind reading, but from real human feedback.
• Be quick to recognise when difficulties are a result of not understanding the first principles of a domain, and seek people to help.
• More actively seek the involvement of others.
• Not replicate the human experience when the human experience is what is needed. Furthermore facilitate the existing good parts of the human experience before augmenting.
• Favor building the community.
• Work smarter, not harder.

If you’ve read the article, you can skip this paragraph. If you’ve just skim read the lessons above, they might not save you if you haven’t personally experienced the mistakes that drive them. Do make sure to ‘firewalk’ my journey above to imagine your similar mistakes and internalise the pitfalls to help yourself recognise them. If you think your case might be different, please reach out to me and I’ll asses your validation of how you know it is ;)

Where I go from here

Pivoting slightly and doubling down on the community. I’m continuing to interview and recruit beta users for the new ProYou Communities.

If you’re interested in your improving your life, and think the help of like-minded, experienced others might be beneficial towards that.

Please share your answers to our short survey.

Filling out the survey will make you eligible to join our beta community of like minded people helping each other succeed.

To join the very next batch, also opt to schedule a 20 min interview, after which, (if you’re interested) I’ll include a 15 min coaching consultation using all my research and practice in behavioural change to help you as best I can with whatever practice you want to improve on. (If you’re unsure how I could help in that regard, remember how powerful these moments of shared attention can be.)

Not interested in ProYou Communities but enjoyed this summary of mistakes? Subscribe to my learning newsletter to learn from my future mistakes in all things product development. Summarised and sent once every 6 months.