Building better products 💭
We see a lot of proof-of-work around these woods. And for good reason when we're changing the world one commit at a time. With this post however I am keen to challenge the notion that we should jump straight into building and ship product updates all day long. And to chime-in with some feedback on what makes a successful product.
It's all very easy to pick and choose new features to add to an early product. To work on many cutting-edge side projects at once. It's fun too! You might listen to your customers and add more functionality. To grow the code-base, to grow the cost-base, with the aim to grow the customer-base too. What normally happens however, is we grow is the 'technical debt' and cater to edge cases. There is therefore one thing founders, particularly technical founders may sometimes need reminding of in software...
More is not more.More is less.Less time to focus on the problem your customers want solving.
I say this because new features when implemented are always hard to find. ~builders may not always know whether Feature Z will be popular or not, and they often don't want to disrupt the core experience when implementing it. Feature Z then gets stuck away in the 'safe zone' - behind a settings screen or multiple taps away, to prevent disrupting the core experience.
The intention of this post is not to sound too preachy, but I am sharing a different perspective to the never-ending pursuit of PRs & adding new features. We should think deeper before we jump into the build phase of any project or improvement. So that we can categorically say whether or not we solved the right problem in the first place.
Avoid trading punches with competitors 🥊
Many ~builders will also jump straight into the ring and decide to compete with existing established businesses, based on existing UX, pricing or quality. This is what we are all familiar with. As bitcoiners we may seek to replicate the fiat product on-top of bitcoin, or to cater to fiat infrastructure completely. Quite often what we are doing with this process however is limiting scope and solutions, and restricting our ability to imagine it being done better.
Attempting to gain customers at expense of other competitors is somewhat of a zero-sum game. It may generate success for your company or startup, but the most impactful and interesting businesses of tomorrow will look beyond that strategy. The best businesses to work on are the ones thinking of a problem completely differently to any other market participants. Creating a completely new customer experience entirely, attracting customers from other industries too. Scroll further down for examples of that in recent history...
Less is more 🔻
Adding features, as mentioned, is easy. Fun but easy.
Removing features is hard. Users shout when you remove a feature they liked using previously. Especially when they have paid for it or invested time using it. It is therefore better to remove the feature before it is implemented. Before it has any users. And that is done by testing, testing before you ship.
~builders may circumvent the lack of eyes in these parts of the product with condescending popups, instructions, emails and FAQs or with cluttered UI. If this happens with your product, it's because a shortcut was taken. Either through insufficient research & planning, fast iteration & experimentation OR too many fires & feature requests to put-out.
I have been as guilty as anyone in prior software projects, favouring quantity over quantity. Even on this particular site, calling-for new functionality like new territory payment terms, editable posts or stacker auctions. Items that may not yet be central to the core vision/problem of the product.
You don't need to ship a feature to establish whether it is worth investing more time in it. To know whether people will use it. Low-fidelity design prototypes, "fake doors" and user testing are easy practices that achieve those very aims. They may sound very "fiat", but they are actually VERY rarely practiced by any company today. And yet they have incredible ROI. The lust for shipping quantity over quality is often too tempting. But Bitcoiners should be thinking about more efficient ways of experimentation. To make best use of their valuable resources & time. To test their creations earlier. Now that would be some proof-of-work.
'Two' Many Problems 2️⃣
1 customer problem to solve for founders is often enough to contend with. 2 may be maximum for any startup. More, and you may spread resources too thin. If as a founder you think you're solving more than 2 problems it's far more likely you're solving none whatsoever.
If it is not a core feature and if it is not something 60%+ of your target customers will use in the next 18 months, then it may not be worthy of your attention right now. Yet many friendly founders cave to the demands of their noisiest customers and neglect the non-vocal newbies that vote with their feet - i.e. by 'retreat'.
It takes relentless experimentation and evolution to eek out the gains from solving each consumer problem. To iterate and improve metrics, to retain your customers and corner the market whilst hungry competitors plot their revenge. If your roadmap consists of solving more than 2 top-level problems, it may be wise to invest some time researching which of those are of more importance to your target customers.
User testing 💡
The tools mentioned, particularly usability testing require much less time over the course of a project and allow you to test and iterate on extremely quickly. If you have never come across the term "usability testing" before here's a taster:
| 3min intro of a testing script | 3mins on testing benefits |
|---|---|
Whether teams decide to admit it or not - code costs money. Shipping and testing & fixing code costs yet more money. Developers & founders often don't value these initiatives upfront, because they justify the next idea as 'urgent'. Plus they like to build cool new things and show the world their proof of work. I do too!
Proof of work matters, but proof of meaningful work matters more. It's imperative that engineering teams incorporate some research into an early part of development, if they wish to ship products that customers truly want. To really understand from the horse's mouth the problem what they are solving and what they are building solves that problem.
I've run 70+ user testing sessions over my time in software. It's by no means enough. Not once has a developer I've been working with not been fascinated or captivated by the findings. And that is not because of my complex insights or clever mind-control techniques. It's because developers often think they know how power-users use their software products. They assume that every customer knows their product as much as they do.
When you see with your own eyes a real user (power-user or not) navigating their way to the profile screen unable to tap the 'Follow' button, or unwilling to read the popup explainer you designed - it's an awakening unlike any other. An awakening to humble you that literally NO ONE uses the product like you think they do.
It's extremely irritating witnessing the struggle unfold in-front of your eyes. You wish to point the user in the right direction, to save them from themselves. But you must persist in silence. You must observe to see how other people are confronted with your product. Whilst they talk out-loud and share what they are seeing and what their thought process is. You will not even need to repeat this process more than 4 or 5 times to spot any recurring themes. And therefore it is an extremely valuable exercise to do.
Even if testing on normie grandparents or reluctant 'rugrats', those developing products need to witness people using a prototype of what they are building. Testing before they write a single line of code. And it can literally be done on paper napkins. Even if it is not a real existing product, using Figma/Sketch/Adobe prototype designs can lead to some interesting findings.
Founders may predict for instance that a drop-off will occur when a payment is sought or an email is required, in the onboarding flow that has been designed. Except the vast majority of users churn and drop-off because they DON'T YET KNOW the value of your product for themselves. It happens when the friction of taking a decision is too much, compared to this uncertainty over what your product offers.
People are fickle & impatient 🤔
Many of us Bitcoiners are more forgiving in this aspect because we want to see tomorrow's future today. Whilst we are risk-averse and critical of non open-source code, we are experimental and will give new exciting products a try. Options are more limited than the fiat world. It's therefore likely we will tolerate more friction than the masses would.
Mainstream users are more fickle however. And therefore there need to be means to overcome this conundrum. As an example, 3 of which are explored below with differing effort:
Low Effort- Reduce the number of decisions required by the user. Allow people to test the product without an extensive sign-up flow, without providing personal details, without even free trials. The only barriers to them using your product are their own time & the perceived user-friendliness of your product.Medium Effort- Hook people in with an inflated expectation of your product and implement 10 sign-up screens that increasingly numb them to the process of decision-making. This is the 'fiat' mindset, that has led to the proliferation of free-trial subscriptions, expiring offers and "personalised" onboarding. Go this route and you'll feel the wrath of @Darthcoin.High Effort- Educate customers with text and engaging illustrations that actually get read by your most lazy users. This requires constant experimentation and refinement. Lengthy text, popups and collapsable UI are not going to cut it here. UI and text must be concise, alluring and incredibly engaging. Here you are almost building a mini product. And doing so with passwordless authentication and public/private key cryptography is really hard. However in the context of onboarding, this could include bite-sized testimonials, 1 or 2 statistics of your top 100 users and no more than one main CTA on each individual page. It could also mean postponing certain setup actions until after account creation for instance, a tricky thing to balance & coordinate.
Iterate to innovate ♻️
Often a problem is defined but the initial solution is believed to be final. Once shipped, teams move onto the next shiny solution to ship. If the product doesn't achieve your desired metrics after launch of the product, you can try a radically different implementation of the same solution. If you have hard data confirming that it is indeed the most important problem for your customers, refining what you have built should help you reach your objective. But that objective needs to be defined upfront.
If you're sceptical when reading this, don't just take my word for it. Read from Will Cole @willcole, an experienced product leader, who had a similar article of his shared on SN titled - Think, Then Do. Discussing the need for definition and measurements for success before you start any development.
Create. Don't Compete 🎯
A great read also for building better products is this book titled
Blue Ocean Strategy.| In blue oceans, competition is irrelevant because the rules of the game are waiting to be set. |
|---|
🔴 Red Ocean | 🔵 Blue Ocean |
|---|---|
| Compete in existing market space | Create uncontested market |
| Beat the competition | Make the competition irrelevant |
| Exploit existing demand | Create & capture new demand |
| Make the value-cost trade-offs | Make value-cost irrelevant |
| Differentiation OR low-cost | Differentiation AND low-cost |
Blue Ocean strategies are successful when they have 1) Focus, 2) Divergence, 3) Simple Tagline. In order to understand a bit better, here's a few familiar examples below...
Blue Ocean Strategy Examples ⚡
Blue Ocean Strategy is arguably what is great about Stacker News today. It is setting the new rules of the game - it is not competing with the likes of Reddit and Twitter. It may have started out as a Hacker News clone - but it is no longer competing with any other legacy social media site.
It is rewarding users for their time, creating a viral network effect of attention and participation. It is opening-up a new market - new potential users. Training poor
pavlov-plebs like me to write more articles like these. Content is available to every user from second 1. No barriers, no distractions and no imagery whatsoever. The content is central to the experience. There is no landing page. There is no marketing spiel (for now).Freedom tech aside, it is very much up to the user to determine the value of Stacker News. And that is incredibly refreshing in 2024. Something to lean into for the future, not to deviate away from. All that is needed is a catchy new tagline... but I'm sure @kr & @k00b are working on it.
More Examples... |
|---|
More detail on those 'Blue Ocean' examples:
- Apple iPhone - During the smartphone era, many manufacturers were creating phones with desktop functionality, merging MP3 players, game consoles, cameras, email, calendar & internet browsing - in a form factor with clunky buttons and small screens. Apple instead invested in developing a more reliable speedy operating system above all else, with a unique user interface. What set it apart from the competition was its simplicity in form, with only 4 buttons and a touchscreen instead of a physical keyboard. Additionally, Apple succeeded for so long thanks to a marketplace of mobile apps made by Apple and third-party programmers, allowing users to customise their phones to reflect their specific wide-ranging interests. And increasing the potential revenue per user drastically. Note: this Wired Article is a good read into the origins of the iPhone.
- Cirque Du Soleil - the circus had previously been a cheap attraction, aimed at children and family. It was also an expensive outfit, travelling around the country with very specialist staff. This company turned that on its head, creating an exclusive show for adults, without the necessity for staff to travel around the country or for animals to appear in shows. Instead they were able to use exclusive venues charging premium 'broadway' prices and creating an entirely new category of show for themselves.
- Airbnb - Offered the convenience of the hotel and the comforts of being at home, with guests getting their very own local guide as 'host'. It is now pretty difficult to imagine a world without it. Hotels were not serving the needs of younger millennials by connecting you when visiting new places. Not only would guests benefit but hosts could too - from the additional income stream for their rented/owned accommodation. There was no true competition for the company, given they had created an entirely new market for themselves and were doubling in size each and every year. In spite of fierce reactions from traditional hotel chains.
- Tesla - This one is still playing-out before our eyes. Tesla knew they couldn't compete on build quality vs German/Japanese manufacturers but aimed to do away with traditional marketing & dealerships, seeing them as insignificant costs & sunk costs somewhat. Instead, they focused on automating the manufacturing and driving experience. Bringing software updates to its fleet that get better for everyone with every mile that each user drives. Adopting battery tech that improves each and every year. Tesla is to become as much a battery and transportation company than it is a simple car manufacturer, regardless of what happens from here on out.
- Netflix - those of us ageing likely remember with nostalgia from the fate of Blockbuster video. That awkward experience of renting movies & having to return them on Monday without fines / late fees. Netflix pitched their idea but were rejected by Blockbuster early on, because sending DVD's in the mail and removing penalty fees sounded ridiculous. Netflix soon outgrew and obsoleted the blockbuster business in just a few short years after. Then most television shows too.
Similar examples are discussed in the Harvard Business Review. Yet none of these case studies could have happened without these firms understanding the customer problem deeply and without doing design thinking and validation of prototypes before they had truly begun building. Hopefully this resonates with you ~builders.
Removing features 🚫
Removing features is much like taking candy from a baby. It is easy but not enjoyable. It will become noisy very quickly, which is why it is almost never done in today's world. I have only really witnessed it done by Google and they are pretty terrible at it. Building solutions to problems that don't really exist but then killing the solutions to real problems without iteration. Removing features & products regularly.
It is painful to founders, and painful to customers alike. But quite often removing features is the very medicine needed to cure the illness of a broken product. If you don't trim your 'bush' so to speak, it will become overgrown and overwhelm the new and high-potential shoots and shrubs that surround it. New initiatives and experiments could catapult products to new viral levels of adoption. My advice would be to remove features however before you ship them.
Landing Smear 🌐
Landing pages today are often inserted to patch the symptoms of a sick product instead. Interrupting the user from getting to the very content that they deserve to see. With the aims of "deceiving" them into sharing something valuable (personal details / currency) before they get to try the product for the first time. This default experience we accept as standard IMHO will likely not survive in the coming years. Not on a more open web. Not when the friction to move your data or money elsewhere is negligible.
Websites in 2024 do look great. Much better than they did back in the 2000s. Stripe's landing page for instance was copied by tens of thousands of sites across the world when it launched. It led to entirely new design trends on Dribbble, a site popular for professional hipsters. On the contrary, simplicity and focus in products has taken a beating in the last 20 years.
Users likely don't care for the wonderfully calming gradient transitions of your site, they have short attention spans and want to clearly see and obtain the value of any product offering. That is what they are landing on your page for. That is why they use the code you built. As ~builders we should speed that process along for them.
Focus on the prize 🏆
The main reason for writing this post was to share that building products demands focus. Focus on real customer problems. Focus on iteration. Focus on UX and simple messaging. Focus too on what NOT to build. NOT just what to build. Once that is squared away, you're off to the races to focus on execution. Unless it's someone else's or your own hobby project, you might wish to start by coding less initially, not more.
Agree with 'less is more'?
If you liked this post let's hear it in the comments. If you're sceptical, give it a try by putting your pet project in the hands of a family member and observe them. Perhaps we'll do a follow-up post on some potential innovative implementations using Bitcoin, or apply more thinking to Stacker News or other Bitcoin companies. What else you think makes a good product? And do you believe testing & research before building is worthwhile work?