According to freeCodeCamp’s 2018 New Coder Survey, 40.3% of participants want to build a business of their own, either as a freelancer or as an entrepreneur.
If you are in that 40.3%, then this article is for you. If you are in the remaining 59.7%, you might still benefit from it. Give it a try.
This is not a “dummies’ guide to strategy and design” or a “strategy and design 101” article. This article is written specifically for developer folks. Not just software developers but also no-code developers. (Shout out to my ODNC1 fellows who encouraged me to write this piece.)
Table of Contents and How to Use this Guide
This is a long article. Actually, this is not an article – this is a guide. So, it's better to read the prologue and give the guide a quick scan. Then start applying the methods rather than reading the whole text and trying to internalize it.
You can only internalize this guide by applying it.
Getting Started
- What is Strategy?
- The Main Components of a Business Strategy
- Strategy, the Scientific Mindset, and Software Development
A Rough Guide to Strategy and Design for Developers
- How to Define Your Purpose
- How to Develop Strategic Hypotheses
- How to Test Strategic Hypotheses
- How to Design Your Product
- Conclusion
The Structure of the Guide
This guide is structured to make the actions you should take very clear. So, in every section, you will be given a little bit of context and then action items.
It is essential that you read the context in full before taking action so that you can see the part the action plays in the bigger picture.
Getting Started
I know that strategy and design can sound, well, fluffy. I know that because I have been there.
I am an engineer. I love physics and mathematics. I love breaking challenges down into their parts and overcoming them one by one using logic. I love to work with hyper-realists who think rationally. I love viewing processes as functions that take certain inputs and spit out certain outputs. I love all of that and more.
However, I am also a strategist and a designer. I know that not everything has natural reasons to be so.
Sometimes they are purely based on choice. I know that people are irrational, though still predictable. I know that people value social and emotional benefits as much as functional benefits, if not more.
So, I know that bringing together strategy, design, and engineering mindsets dramatically increases our chances to achieve whatever goals we have. I witness that day in and day out thanks to my job at ATÖLYE as its Ventures Director.
But if you don't believe me, I hope you will believe in the data. This might be one of the saddest statistics you might ever see (!):
CB Insights’ findings are chilling. 42% of startups failing simply because they are not needed.
Imagine this: You quit your job, and maybe risked your reputation. You raised funding from your friends, family, and investors. You started living on a very low budget. You worked tirelessly, 12 hours a day if not more… and after a year you realize there is no need for what you have been grinding and hustling for all that time. Isn’t that chilling?
Strategy and design help you minimize the chances of failing. How? Good strategy and design focus us on building lasting businesses based on customer needs and/or wants and competitive advantages. Also, they inherently mean testing hypotheses and iterating constantly.
They are great tools to find our way out of complexity… but let’s leave praising strategy and design aside and get practical. We will start by agreeing on a definition because the meaning of strategy is highly variable.
What is Strategy?
Strategy is one of those concepts that everybody understands when they hear it but no two people understand the same thing.
Very generically put, strategy is a high level plan to achieve pre-determined goals. However, in a business context it has a more specific definition. Here is how I would describe it:
Strategy is a set of hypotheses that describe a set of integrated key choices, key actions and a progress measurement framework for achieving business objectives.
We develop strategies because we believe achieving objectives will help us realize our purpose.
The Main Components of a Business Strategy
Below are the most relevant main components for a startup founder at the beginning of their journey.
If we were to consider an established company rather than an early stage startup, we'd have to think about competitive advantages, core capabilities, management systems and – depending on the type of business – a few more specific components.
The key thing to remember is that however many components there might be, they all have to be integrated with the main components listed below.
The purpose for doing business
What drives you to do business? What impact and value do you want to create? What do you want to get in return? How is it measured (directly or indirectly)?
I list this first because it is the basis, ideally, upon which all your decisions will be made. When you are in doubt or things are too difficult to figure out or mutually exclusive options are similarly attractive – you will come back to the basis and seek guidance.
Market definition
Who are the customers, users, competitors, regulators, and other main actors who take part in the value exchange you want to create?
Market definition and Value proposition are extremely intertwined. That is why I list them one after the other. Without a sharp, even discriminating, (as in consciously choosing not to compete in certain markets and thus choosing not to serve certain customers) definition of a market, we cannot define meaningful value propositions.
Say that you are developing an analytics product. If you are focused on mobile applications then you are "discriminating" against web applications and your value propositions will be shaped with this choice.
Value proposition
Your value proposition is what you have to offer to your customers (and, if you are thinking more ecosystemically, to all the actors you have in a give-take relationship) in exchange for the value you ask from them.
For example, customers pay you money, users might provide you with data, partners might help you reach customers, government supposedly ensures a fair market, and so on.
Value propositions are not the same as products, features, or services. An easy way to distinguish value propositions is to answer the question, "How will our customers benefit from using our product?" (And, again, you can extend this question to all the key actors in your market by asking "How will this key actor benefit from being part of the value equation I'm creating?")
As this question implies, it is not the product itself that your customer is after. It is the benefits that your customers are hoping to get out of using your product.
Meaningful Differentiation
Why will anyone choose your product over all the alternative products or ways to get the benefits they seek? What makes you a better fit for them?
How do you create that fit? How are you doing that differently from your competitors? How long can you hold on to this difference?
What can you do to keep the competition away? How might you make the competition irrelevant to your customers?
As Jobs to Be Done (JTBD) theory explains, jobs (the things people are trying to get done using products) do not change. The products keep changing but jobs stay more or less the same.
Take commuting, for instance. The way we commute has been in a constant evolution that brought autonomous electric cars to our lives. However, the job of getting from one point to another has been with us from the very beginning.
With every step in this evolution, more and more nuances are addressed. However, at the heart of it the job is still the same.
So, the differentiation lies not in inventing new jobs but in finding new and meaningful ways to help with getting those jobs done.
Price is just one way to differentiate. Features, benefits, the overall experience, the nuances you choose to address – there are countless ways to differentiate.
However, meaningful and lasting differentiation is hard. It's hard because copying is easier than ever. It's hard because developing software (unless it's something super advanced) is getting easier and easier. Good design is more accessible than ever.
So, we need more than design and technology to sustain a meaningful differentiation. More on this in the design section.
Strategy, the Scientific Mindset, and Software Development
Strategy is about developing hypotheses from a mixture of deductive and inductive reasoning and then measuring progress against objectives.
It requires us to break things (markets, value propositions, differentiation, and so on) down to their parts (customers, buyers, users, partners, regulators, products, services, experience, branding), understand them individually, and then melt them together to create a coherent whole (a business).
It's extremely analytical and holistic at the same time. I find these aspects of strategy very similar to the scientific mindset.
This similarity also reminds me of the role of a software architect. They are tasked with a similar challenge. The level of uncertainty and complexity, though very different in their nature, are similar.
They both have some level of information available to them to make decisions but never the full picture. They both need to develop hypotheses and test them before fully committing to a particular approach.
Crucially, they both are aware that there is no one way to achieve the objectives, which means they are making choices. So, they want all the other things that will be built on top of their strategy/architecture to be coherent with their key choices.
And this similarity makes me question why so many engineers and developers distance themselves from strategy. Probably because of the way we talk about strategy and position it in companies, but also in education. That's very sad and needs to change.
A Rough Guide to Strategy and Design for Developers
Definitions are important. They help us develop our own language and communicate. Now that we have our language in place, let's get into execution.
The guide below is rough by design. It's rough because I don't want to put too much emphasis on the guide itself.
It's rough because you are a developer trying to get something off the ground. Not a strategist or design manager in a company setting.
It's rough because it aims to hit the sweet spot which helps you get 80% of the results with 20% of the effort.
And it's rough because this is my first attempt to customize it for developers and I want to test this hypotheses before fully committing to it. So meta, isn't it? :)
How to Define Your Purpose
Start from within
What are you hoping to achieve for yourself? A side business? A learning project? The business of your life?
Describe a day in your life assuming everything went great and you have succeeded. What does a usual day look like?
Continue with others
Again, imagine everything went great and you have succeeded. What impact did you create on your customers', users' and partners' lives with that success? How did things change for them?
Action: Summarize and posterize. Try to boil everything down into a paragraph that describe a future state for you and your customers. Rewrite and rewrite it again.
Pay attention to every word you use and make sure that the paragraph sits comfortably with you. Then print it out and keep it visible in your working environment.
How to Develop Strategic Hypotheses
Start with customers
Wanting to serve as many people as possible is great. However, it is very difficult to create a product that will serve a majority of a big market from the first day.
There are many reasons that will prevent your target customers from changing their way of getting the job done: Switching costs, human resistance to change, even inertia can be considered a reason.
So, if change is so difficult, what should we do? We start with a super niche group of people who are most open to change. So, naturally, that's a very small part of the potential market. That's how it's meant to be.
Thinking in terms of Blue Ocean Strategy is very useful for identifying people who are most open to change. Ask yourself:
- Who are most dissatisfied with current solutions? Why?
- Who needs a solution but isn't finding any of the options are good enough? Why?
- Who is disregarded by current market leaders? Why?
- What are some common attributes of these people?
- Do I know anyone who fits to this description?
- Where can I find more people like them?
Then go talk to them. This article has ALL the things you need to know about the Jobs to Be Done approach.
Action: If you want something a little simpler for customer interviews, use this article about the idea of "Push and Pull" to clarify who your customers are and what they need.
Identify your value propositions
We value practical benefits. We expect products to provide practical benefits first. For sure.
However, especially in software, practical benefits are not enough to meaningfully differentiate ourselves. They are easy to copy. “This is the way the tech industry works”. So, what can we do about it?
Luckily, people are social and emotional beings. So, we can add social and emotional benefits to the mix and provide more value as well as making it more difficult to be copied.
Social and emotional benefits are the things that make people say "yeah, it's similar but not the same...".
Think about a product you really like. Not just how it works but the feeling of using that product. Then compare it with an alternative that gets the same practical (functional as it is called in the theory) job done. See how you feel about it.
So, how do we know what social and emotional value to provide? First, it comes from your interviews. You need to pay attention to things beyond functionality.
Second, it comes from your choices. Yes, your choices. There will be lots of options for providing social and emotional benefits. You need to choose ones that will sit well with your purpose.
Action: Use Bain's Elements of Value to identify your options. They have a B2B version, too.
Define your position
Now, you will make things crystal clear by defining where you stand. You'll do that by defining polarities.
Polarities help because that's essentially how we tell things apart. Think of the role of contrast in our ability to see. Similarly, we need a clear contrast for things we do and don't do. This will help us clarify our scope and also crystallize our value propositions for the super niche group of people we are targeting.
Action: Use the More About Less About technique to define your position.
How to Test Strategic Hypotheses
Testing, contrary to what you might expect, is more of an art than science. Yes, it is at the heart of scientific method, but designing tests requires imagination rather than analysis. Analysis only comes after you conduct the test.
Let's look at a very high level overview of the test process:
- Decide what to test and what results count as success. In other words what numbers and/or feedback would show that your hypotheses are valid.
- Devise a test from which you can trust the results and can execute as cheaply and quickly as possible. This is where you need more imagination and divergence (expanding options without judging them) rather than analysis.
- Run a few dry-runs to mitigate failure due to simple mistakes. Learn from dry-runs and iterate.
- Run the test and closely monitor the results to learn from them.
- Analyse the results and decide the next steps according to your learnings.
Testing is extremely tactical and context-dependent. That is what makes testing more of an art than science for me.
That's why, instead of following a strict process, I believe that you'd be better off getting inspired by the following articles and finding your own way of testing. Much like an artist would do.
Actions:
- Learn about the concept of Riskiest Assumption Testing (RAT).
- Identify your riskiest assumptions. (p.s. I don't agree with the notion of MVP in this article. I strongly suggest you disregard it. I wrote about how I like to think of MVPs here.) Assuming you are at the very early stages of your endeavor, it's more likely that your riskiest assumptions will be about the problems, needs, and wants of your customers and how your product can help them.
- Choose the type of MVP from this list that would be the most suitable for testing your riskiest assumptions. Build a rough version of that MVP. Do dry runs and then launch the test.
How to Design Your Product
Now that you've developed strategic hypotheses and tested them, it is time for you to build things, right? Wrong. Not so fast.
One of the biggest blind spots I see in developer-led startups (software, low-code, no-code) is Design. Design with a capital D.
What do I mean by "Design with a capital D"? Often, the design work in the software industry is reduced to how things look and feel. Sometimes, people go beyond that and add the simplicity element to the mix. Making things easy as well as beautiful.
But that's not all there is to designing products. There is more. Much more.
How much more? Well, so much more that I wrote the article below to describe my personal principles for product design and management. I don't think you need to read it or create your own principles, because I assume that your aim is to start your own business. Not to become a product designer or manager.
However, I'd highly recommend reading the Design and Brand Strategy sections of that article if you are curious about what I mean by "Design with a capital D".
UX Collective
Let's leave the philosophical discussions aside and get practical. Below is an overview of the process I recommend for designing your product. I have summarized the philosophy behind this process in the article above:
Unless we have to invent something new, we are much better off using patterns, heuristics and principles without forgetting to adjust them to the problem at hand. This way, we’ll give people (both users and business owners) what they want: Familiar Done Differently.
Consider your customers' context
Start with considering your customers' immediate context when they use your product.
What's happening? What happened before? What will happen after? What are they trying to get done? How do they feel in that situation? In short: Don't focus on the "why". Focus on the "when".
Think about related products
Consider the other products they use to get things done in relation to your product, as well as competitors' products.
How do those products work? How do they talk about themselves? Any common patterns in their design, branding?
If your product plays well with related products and if it is familiar to your customers, then it's more likely they will adopt your product.
List out your product's features and choose the most important ones
It's important to list the features your product will have and then choose yourself a few North Stars.
You'll "steal like an artist" from these North Stars.
Say that your product has a question and answer feature. Quora would be a good North Star as they are all about Q&A's and have been around successfully for many years.
You can also choose North Stars for your branding, look, and feel. The key is viewing them as a solid starting point rather than things to imitate.
Dig deeper into your North Stars.
If you've chosen a North Star for a specific feature, then use it several times. Try to break it. Take notes on how you'd do something differently and why. Do that for all your North Stars.
Start your design with a user flow, not with a wireframe or any visual technique. One of the biggest mistakes you can make is to start designing the user interface (like screens). As I like to say, “Remember, we are not designing things. We are designing behaviours.” So, we must start with actions rather than interfaces.
Break your product down into features
You will need to create user flows for each feature, but how do you break your product into features?
Luckily, Ryan Singer has given a demonstration of how he uses the shorthand for UI and how he breaks things down into their parts. Watch the entire video.
Use Ryan Singer's shorthand for UI to design user flows.
This will save you hours if not days. You may have ideas for the interface while doing the user flow. Just scribble them somewhere and take a note but never focus on them until you are done with the user flow.
Test your user flows
Once you have a rough first version, test your user flow(s) with a few potential users.
Simply, first give them a quick walk through. Then ask them to critique it by thinking out loud.
You may ask them questions to kick start the conversation: "What did you like about this? What would you change? Why? How would you change it? What is this flow missing?" and similar other questions.
Improve your user flow(s) accordingly.
To design the interface (how things will look) go back to your North Stars. But before that you need to establish an overall look and feel through choosing colors and fonts.
First, choose a font pair from this list. Try to make it familiar to your customers but also try to choose a pair that gives the feeling you want your users to have while using your product.
Next, choose a color palette. Try to choose a palette gives the feeling you want your users to have while using your product – but also try to make it different from your competitors.
Action: Use this article to choose your main colors. Then use this website to create a color palette based on your main colors.
Design your interface in detail
Now, you are ready to design the interface in detail. This is where stealing like an artist will come into play, again. Since, you've already made color and font choices, you can focus on the layout.
Go back to your North Stars and base your interface design on their existing designs. Don't change things unless you have clear reason for changing them. Check out tools like Mobbin for further inspiration.
Remember – design doesn't end with the interface. An extremely crucial and very much overlooked element of Design is the copywriting. So much depends on the language.
It's a great contributor to usability if it's clear enough. It gives your design a deeper character if you can strike a chord. It allows you to test things faster, easier, and cheaper. It's extremely important. I highly recommend investing serious time in it.
Action: Read the basics of microcopy, first. Then continue with writing your copy based on these rules.
Go back to strategy
In the endless iteration spiral we call building a startup, at this step of the Design process, I suggest you take a step back and go back to your strategy.
Specifically, go back to your Purpose and Positioning and see whether what you are building actually fits them. Of course, you don't have to and shouldn't wait until this step. However, make sure you take a critical view of everything and see if you are still after the thing you set out to achieve.
It is fine if there are changes. It would be useless if there were not any changes after so much testing and learning.
However, if the very essence of your purpose and positioning is changing then it's a strong sign that you need to rethink things thoroughly. Otherwise, you might find yourself constantly and mindlessly "pivoting" toward whichever direction might seem interesting at any given time.
This will derail you from the long-term vision that you need to strive for. If you don't have such a vision (which doesn't need to be groundbreaking or world changing) then it'll be very difficult to persist through the challenges in the short-term.
Conclusion
Like any other guide, this guide is incomplete, too. Trying to provide a complete guide is almost an oxymoron in itself.
The purpose of this guide, very similar to an architecture or a model, is to provide enough guidance so that it captures the essence of the reality in the simplest way possible.
It is up to you, the entrepreneurs, to figure things out where this guide falls short and creates uncertainty. That, coincidentally, is the ultimate skill entrepreneurs need to have: Figuring things out under extreme uncertainty.
So, I hope this guide will help you with removing some of the uncertainty you are dealing with and accelerate your journey for achieving your purpose.
Let me know what you think and how I might improve this guide. It's an early prototype of something bigger I'm working on. So meta, I know.