Welcome to decision making central. Can I interest you in today’s difficult decisions? Uh yeah, no thanks; I’d prefer the easy button please! If only life were that straight forward, and we didn’t need to be troubled by hard decisions. Well back in the realm of reality, you will be faced with a variety of difficult decisions when designing a digital product. We have gathered what we believe to be the most commonly faced challenging decisions; six to be exact.
Focus & Specificity
Let’s begin with an introductory and overarching point; that being, the focus and specificity. It will present the client with recurring difficult decisions. Consider that there are many ideas, endless ideas in fact from clients, but alas, not all of them are achievable. The first thing to do is figure out which idea is truly worth pursuing. Deciding which idea to go forward with and which to leave behind can cause plenty of anxiety. To reduce that anxiety, it’s important to understand the value proposition of said ideas.
However, this is just the beginning. Now consider: What is the pain point and how can it be solved? Once the value proposition is understood, this question can be addressed. Remember that it’s never a good idea to think you’re going to create the next super app. Therefore, pinpointing the specific pain point or opportunity to capitalise on will be the best approach and lead to a successful product. Staying focused also means not getting distracted by the shiny things; features you may want that are not necessary or perhaps don’t even add value. Do what you know will work, then you can focus on improving it.
This is a big one and one that is not easily navigated around due to the fact that it’s a difficult thing to say, “You’re wrong.” Assumptions, naturally as we all know and accept, can be wrong; however, that doesn’t make it any easier or more welcomed to challenge a client’s assumptions. Just because the client says they know X, doesn’t actually mean they truly know X and you will find yourself needing to continually challenge their assumptions and deal with tough “What’s the correct approach?” decisions. Often what works in the analog world, doesn’t always translate to the digital world.
Typically the client will have good insights about the audience; it’s safe to assume the client knows their customer base. However, they’re coming from the business side of things rather than from the audience perspective. Therefore, does the audience truly want what the client thinks they want? More often than not what the customer wants is not driven by profit, instead by the desire to save or get some specific functionality from the product.
This creates inherent biases in what the client believes their audience wants and therein is best for them, before any real world testing is done. A similar mistake seen from clients is when they decide to base a very big concept on simple anecdotal evidence. Anecdotal evidence has its limitations and it’s important to know them and not base investment strategies on them.
Client Expertise/Domain Knowledge
Continuing here with the client’s expertise and knowledge; they typically know their business field well and they have a genuine desire to innovate and improve it. However, keep in mind that they represent a very small percentage of their own field and even though their understanding and knowledge is more than most, it doesn’t mean it’s correct. Try telling that to your client who has 20+ years of experience in their field; a soft touch is needed.
For example: Do they know what is trending in their domain?; Do they know what the industry is missing?; Have they correctly identified the pain points? All these are key questions to address for sometimes it’s hard to see the forest for the trees. Do they really know what is missing from the industry or do they think they know what is missing? The distinction here being that if something is missing and sold by a competitive industry, that’s much better evidence than the client simply thinking something is missing.
Another point to challenge is the concept of digital innovation. Many clients believe that creating a digital product is creating a tool which inherently equates to digital innovation; sadly you will need to burst that bubble. Digital innovation requires you to break down what you believe is the existing status quo. Thus creating an app to simply solve a problem is nothing more than improving efficiency, not digital innovation.
For example, Microsoft Excel was not digital innovation. Before Excel you could still make a chart, graph and so on, but what Excel did do was make it faster and better, more efficient and effective. However, the power it put into the users hands, raw mathematical power, was a form of digital innovation. So it’s important to challenge the client here. Are they trying to just create a new tool, or are they trying to steer the industry in a certain way.
The final tough one here is just because a client knows their business well does not mean they know how business works for a digital product. Going back to what we stated earlier, what works in the analog world, doesn’t always translate to the digital world; how digital products work and are monetized is completely different. For example, digital products give the client the ability to hit mass markets faster than in any other industry. Therefore, the business approach needs to be different to reflect the business of the times now rather than yesteryear. Digital business models are a nice concept yet extremely complex ones that often disrupt & diverge from traditional models. In order to create a feasible long term business strategy which includes monetization, seeking the opinion of a digital business expert is a good starting point.
Budget & Timeline
Budget and timeline, oh my these two points will find a way to permeate nearly every discussion at every opportunity they get; you are thus forewarned. Naturally so though as they are always present and always a concern; all clients work within a specific budget and timeline. Specifically, what the client thinks is an appropriate budget and timeline will need to be challenged. You might be thinking, “Why is that?” As mentioned earlier, the client may know their field, but they likely don’t know the digital area of their field nearly as well as they think they do. Thus their understanding vs the real cost of digital products will not exactly line up in their favour.
During the design & development, problems often arise, problems that are unknown and therefore, cannot be perfectly budgeted for, which naturally throws a monkey wrench into the mix. If the client happens to come from the digital field, then you’re in luck, but otherwise be prepared for more difficult challenges and decision making. A plan is only useful until it is challenged; therefore, taking a proactive stance by coming up with contingencies and an agile approach will aid in execution. Working on a retainer is a good solution as it allows for changes in the design, development, client’s opinions and so on.
MVP & Prioritisation
Here we come to the MVP and prioritisation; MVP being the minimal viable product. This brings us back to our earlier point above when we discussed the scope, and the desire of “I want to create the next super app” client mentality; it’s simply untenable. A more appropriate approach is something that follows the agile methodology where you work in an iterative way.
If you’re able to identify a certain list of features that must exist in order to provide the minimal viable product, you’re much more likely to create a sustainable growth model for your digital product. This will allow for the product to be iterated and receive feedback; feedback prior to completing everything is extremely useful for budgeting and ensuring the concept is sound and has market demand. It can also aid in gathering funds through more standard fundraising models where you create a series of MVPs in order to secure alternative types of funding. Though deciding where to draw the line is the challenge hidden therein as no one is very satisfied by how little each MVP delivers. Stay focused on “minimum,” it’s not about creating a version of the product yet.
The other key takeaway here is the ability to do user testing with each iteration before planning out the entire software. Valuable feedback can ultimately alter your approach as needed. Just remember that users are biassed so finding the balance between the client’s aims and the users’ wants is key; users only know what they want based on what exists. No one knew they wanted a smartphone until Apple dropped the iPhone on the market.
The reality of monetization is quite often harsh in the digital world. Many people have great ideas for digital products, but sadly too many are untenable as they fail to find a way to incorporate monetization or perhaps haven’t even considered it. In fact, monetization should be one of the first things on the list to consider. High price works best for premium products or highly complex & unique solutions. In other words, be the best or the only and you can ask any price. For everything else, volume is a more effective approach.
Monetization needs to be baked into the product from the beginning and not inserted as an afterthought later. Now it can and likely will be the crux of the product design, but this does not have to be a bad thing. Consider mobile games, their entire games view monetization as a feature that influences every part of how the game is played and ultimately enjoyed by the user. Therefore, ironically leaving the user excited rather than irritated for having to spend money; yet too much pressure has the opposite effect.
A digital product is an investment, and a large one at that. It creates a value proposition that needs to deliver a real world return on investment. So considering this point from the beginning is a must; especially when developing from an iterative position as each iteration is not going to deliver the volume required to fulfil the value proposition. When you bake the monetization in from the beginning in small, digestible doses, the user is more likely to accept it rather than walk away from the app or product. Monetization as a feature, sadly the most hated one, is still the best approach to getting this key point decided and implemented.
UX: Good vs Bad
Good and bad user experience: a simple concept, right? Yes and no as what is beneficial for the user is not always what is good for the client and their business. Surely we want a product with a good UX; unfortunately reality dictates that it will not always be so. The way this works is the best UX is an app that does everything for the user for free. As we mentioned above with the baked in monetization being the most hated yet begrudgingly accepted feature, it will always taint the UX, therefore marring its good name.
Why is this? Simply put, it’s not a valid business model or valid product; with the natural exception of for example, a charitable app. Of course, if you’re a charity or NGO then it will work for you. Otherwise, the app or digital product will inevitably need to ask the user to do things they don’t want to do; e.g. signing up. People are increasingly sensitive when it comes to privacy and rightly so, but the reality is the app needs the user’s information to create the user profile. Therefore, creating trust and a positive long-term relationship with the user base and software/business is a must to get the user to do those things they don’t inherently want to do, but will do if there is trust.
From the client perspective, their main focus is to provide a product the users need. Though in order to create a sustainable business model, they need to monetize it, monitor and regulate it. No client wants users posting profanities or other negative things in the app to name a simple example. Accommodating for such scenarios is imperative in addition to building specifically bad UX that is packaged in the best possible way.
As we come to an end here, you can see that these points present considerable challenges to the decision making process not only before development begins, but even once development is underway. For both the tech vendor and client, being aware of these items can aid with a smoother process and journey to creating the necessary digital product desired. So, happy decision making!
Tag CloudAgile - Agile Delivery - AI - amazonecommerce - Animal Framework - Attracting talent - Autonomous weapons - B2B - blockchain - businessbuilding - Business building - Clean code - Client consulting - cloud platform - Code Refactoring - coding - Company building - Computer Vision - Corporate startup - cryptocurrencies - de-risking business building - Deepfakes - Deep Learning - DeepMind - derisking business building - Design Research - Developer Path - DevOps - Digital Ownership - Digital Product Strategy - ecommerce - entrepreneurs - Figma - founder equality - founder equity - front end developer - Fullstack Engineer - Growth strategy - Hook model - Incubator - innovation - Iterative and Incremental Development - legacy system - Manual Testing - Metaverse - methodology - Mobile Engineer - Natural Language Processing - NFT - NLP - online recruitment - playbooks - Podcast - Product Design - Product Development - Product Development Strategy - Product strategy - product versions - project management - Prototyping early-stage ideas - Quantum Computing - Recruitments - Remote Work - Research - research problem - Robotics - Sales machine - scalable software - Scrum - Self-Driving Cars - Serial entrepreneurs - Slash - software - software design - Software Development - Software Development Company - Software Engineering - Spotify Model - Staff Augmentation - teamwork - Tech Talks - tech teams - tech vendor - testing playbook - The Phoenix Project - Unit testing - user interview - user retention design - VB Map podcast - Venture Building - Venture building strategies - Venture Capital - venturecapital - virtual retreat - Web3