Designing and building a software product during the early stages of a startup requires a different type of mindset.

Software startups are fun and fast, allowing you to pivot and switch to new ideas within hours. Product development is agile and productive. The entire team contribute to ideas and feedback. Meetings are full of passionate disagreements as everyone argues for a better version of the product. In my experience it is extremely rewarding.

At the same time you also have very limited resources and need to move fast to build a profitable product before funds run out.

Product managers at early stage startups should try to adopt a mindset which will allow them to move fast, remain focused and build a great product. Complex product management tools, reports and processes can be important later on but perhaps certain attitudes and concepts could be more effective at first.

These ideas may seem obvious — but they can prevent situations where a team ends up building things that are not needed and creating an expensive & complex product that no one wants to use or maintain. They help to ensure that all effort is only focused towards the work that needs to be done and nothing else.

Over the years as a software startup co-founder, developer and product manager — these are the concepts which I have found to be the most effective in creating good software products:

  1. Roadmap Laser Focus
  2. Understand the problem you are solving
  3. Missing the wood for the trees
  4. Question Everything
  5. ‘Be lazy’ and keep it simple!
  6. ‘Ignore’ Feature Requests
  7. Protect your Team, your Product and your Users
  8. UX vs UI

I’ll try and explain each of these ideas in the rest of the article below.

1 Roadmap Laser Focus

Focus does not mean putting your phone on ‘do not disturb’. It doesn’t mean answering emails in a predetermined hour and ignoring them for the rest of the day. It doesn’t mean focusing on the task at hand and ignoring your team for hours each day.

Focus means setting out a long term and high level product roadmap and then sticking to it!

Each day will bring new feature requests, potentially large client deals that require customisations, colleagues from the sales team asking for a particular feature and developers suggesting changes.

Addressing each of these requests is tempting. You will also feel that, as good product manager, you should be receptive to all these requests. After all, shouldn’t a good product manager make sure we get as many sales as possible and meet all customer requests?

There are 3 reasons why a good product manager says ‘no’ more often than ‘yes’:

  1. Time and resources are finite - We cannot build everything! The development team is probably already overloaded. We’ve set target dates and made commitments to customers. Keep an eye on the goal and keep your head down.
  2. Nobody wants a complex product with too many features - Implement every feature request and you will give the user too many options and compromise quality for the sake of doing it all. The end result will be a bloated product riddled with bugs. Many features will only satisfy a very small cohort of your user base, while inconveniencing the absolute majority. The cost to your user base will be lower quality, poor performance and higher prices. Customisations for the sake of a single large customer, will slow down all future development and increase technical debt. In addition, the time and resources used for this bespoke development would have been better applied to improving your product and racing through your roadmap.
  3. You set out a roadmap for a reason - The company has a strategy and a vision. This was set out in your roadmap at a time when your vision was clearer. This roadmap is the story you are telling your team and your customers. Be faithful to it.

The roadmap will change and there will be times when you must pivot, but this can be done a few times a year at most. It should be done deliberately (consciously and intentionally) and only when it benefits the overall company strategy and vision.

2 Understand the problem you are solving

Good software does one thing and one thing only. It solves a problem (or problems) for the user in the best way possible.

So you now have a good roadmap and the laser focus required to deliver it. The next step is understanding exactly what problem or set of problems each feature on your roadmap is actually trying to solve.

Throughout the years building our products, there were many times when I found that I was working on a feature without actually understanding the problem that we were trying to solve.

Even worse — I sometimes found myself putting effort into a feature which was solving a problem that no-one cares about.

Users ask for a feature, but they do not normally tell you the problem they are trying to solve.

They will tell you — ‘put a button at the top right which will export the list to CSV when I click it’. Why do they want to do that? What will they use the data for? What pain point are they currently experiencing with your product that is making them download the data in CSV format and then process it outside of your product?

If you understand the problem they are trying to solve, then you can start to design a great feature.

This sounds obvious and easy, but in reality it is one of the hardest things I have found when designing software. It is too easy to take things for granted. You need to put on your customer’s ‘glasses’ and view things from their perspective. Understand what they need to achieve and design strictly to solve that problem.

Once you understand the problem that needs to be solved — then it is important that everyone on your team understands the problem too. The developers building the feature need to understand the motivation behind it too, as do the QA testers and the tech support team.

3 Missing the wood for the trees

I often found myself using this phrase during meetings. During every project there came a time when we were so involved in the details that we couldn’t see what was important about the project as a whole.

So how would this happen?

  • Projects would kickoff as a long list of JIRA tasks and stories. Each broken down, costed and prioritised into never ending boards with colour coding and labels.
  • Before long; meetings and discussions would no longer be creative and productive. They would become mundane and involve the tedious discussion of each task, its priority and its problems.
  • Each team member would have their own list and lose visibility of the feature as a whole.
  • The bird’s eye view would quickly be forgotten as we would firefight one task after the other.

Busy months would pass by and we would start with sprint demos and MVP builds. The only problem would be that the feature just wouldn’t feel right. Perhaps the original design or requirements were not thought out properly. Perhaps issues arose during development.

The problem is that we forgot about the big picture and would have been so concerned with the details of the project that, when combined, the feature as a whole would fail.

Keeping a bird’s eye view

I do not know how to prevent this from happening — but I did learn an important lesson.

User stories, JIRA tasks, lists etc. are not a good way to share a feature vision.

You must first build your feature on ‘paper’:

  • Draw quick wireframes. Use whiteboards / pencil and paper if need be.
  • List the problems you are solving and the solutions you are proposing.
  • Understand who the end user will be.
  • Present high level user facing requirements.

This is what needs to be shared with the entire team. Everyone needs to understand exactly what we are building, for whom we are building it and why we are building. They need to understand it from a bird’s eye view.

By doing this you have drawn out the feature in a way that can be visualised and understood by all stakeholders whether technical or not. This is powerful because it allows you to get feedback from different perspectives.

  • Hold talks with the tech support guys — do they envisage any issues during customer upgrades?
  • Survey partners — can they sell the feature to their customers?
  • Present to the marketing team — allow them to start building content in preparation for or the release.
  • Speak to technical operations — can they influence the architecture at this early stage?

Once the feature is understood by everyone and you have enough feedback from the right stakeholders you can now use Lists and User Stories to manage the development life cycle — but continue to use the high level user facing features and visuals during meetings and discussions.

4 Question Everything

  • We need to upgrade to the latest version of the library! — Why?
  • We need to support a different platform! — Why?
  • The code needs to be refactored! — Why?
  • Customers are asking for feature X! — Why?

You need to play devil’s advocate and question every request and every requirement before it is written.

  • Is it needed?
  • Did we understand it?
  • Is it needed right now? Can we delay?
  • Does it need to cost so much?
  • Go back to the customer and ask them why.

More importantly you also need to ask these questions to yourself. Question your own ideas and requirements constantly.

Ask yourself:

  • Do you really know what you are saying?
  • Are you insisting on an idea because of your ego or because it is really needed?
  • Did you screw up the original requirements?
  • By questioning everything you will be reinforcing the team’s laser focus.

By doing this properly you will protect your product from bloat. You will protect your team from wasting time, and you will protect your customers from higher costs and lower quality.

Question everything but don’t demotivate your team!

You need to find a way to do this without being abrasive. It is important that new ideas are raised and accepted when necessary — if it is not done properly then it can backfire and reduce creativity and improvements to the product.

You also need to ensure that your team question you and your requirements. The best features we developed were the result of a developer questioning the product team’s requirements, insisting that they were flawed and proposing a better alternative

5 ‘Be lazy’ and keep it simple!

Being lazy is not really compatible with building a software product. But it can be an asset if it allows you to achieve the same results by doing less work.

Another way of looking at this is that it is easier to build a complex monster than find a way to do it in a simpler way.

An example of this is when discussing whether to support an additional platform. Do you really want to have to release every future feature on this additional platform? Do you want to have to train the tech support team and build out additional documentation.

Is it worth the extra effort?

Many times the answer is yes because it will improve your product and generate more revenue.

Sometimes though it’s might be better to be ‘lazy’, maintain your laser focus and direct your energy where it can be really effective.

This lazy approach also applies to keeping your product and its architecture simple:

  • Try reduce the moving parts
  • Reuse libraries when there is no need to rebuild (it is always tempting to rebuild!)
  • Reduce the options in a feature if they are not needed

I can think of many examples when this approach worked out well. For example (depending on your type of product) there might not be need to support and test on all web browsers. You can limit support for certain older operating systems to reduce overheads. Choose which cloud platforms you want to support and ignore the rest.

There will always be a small number of users asking for support for some obscure feature or platform. These are often the most vocal ones who will broadcast their requests all over your forums and support platforms.

Sometimes being ‘lazy’ and keeping things simple will once again protect your team, your roadmap and your customers.

6 ‘Ignore’ Feature Requests

Ok, let’s be honest, you cannot really ignore feature requests.

The idea here is to track all feature requests, prioritise them by occurrence, understand them… and then forget about them.

There should be scheduled meetings throughout the year where the feature requests should be evaluated and perhaps some may influence your roadmap and project plans.

It is important though that the feature requests do not become a daily distraction, where the attention and efforts of the team are lost in the noise and are driven primarily by feature requests. Doing so is like trying to predict the tide by watching the waves.

One way that we attempted to do this is by keeping feature requests in a separate project from the active project backlogs. This reduced the noise that we had to deal with on a daily basis.

If a feature request did make it to the roadmap — then it was no longer a feature request. It has now objectively and thoughtfully been made part of the product roadmap and strategy — because it deserves to be.

7 Protect your Team, your Product and your Users

This is a simple concept, but it is a critical mindset for any product manager.

Consider this scenario:

  • In a single day a product manager can stitch together a list of requirements and approve the costings — submitting them to the developers.
  • The development team then take weeks to build out these requirements.
  • The QA teams also take weeks testing and accepting these changes.
  • The technical operations build out new infrastructure to host this new code and this costs money and takes time.
  • Marketing teams build a campaign and update the website.
  • Tech support build KBs, train team members and create documentation.
  • Users take time to install updates, learn new functionality, and perhaps suffer through new bugs.

Now consider that the product manager did not maintain laser focus. Perhaps they did not question everything. Perhaps they let the most vocal customer influence them.

Perhaps these requirements did not add value to the product. Perhaps they will not result in additional revenue and new customers.

The teams have spent weeks building code that was not needed. They complicated the code base a bit further. They are now managing infrastructure that is not needed.

Worst of all they have delayed other projects, reduced team morale and did not serve their customers well. The roadmap has taken a detour.

A few critical mistakes by a product managers, will cost large amounts of resources down the line.

Protect your team — by ensuring that they only spend time on relevant requirements which will add value.

Protect your product — by ensuring it is not bloated with unwanted features, or complicated by extra code.

Protect your users — by ensuring they do not pay higher costs or get lower quality due to features they do not need.

This concept of protecting your team, product and users can also be viewed in the context of rebuilding or refactoring code. Developers are always pushing to rebuild, refactor or redesign some part of the code base. There is always some new technology they are excited to adopt.

If the code has been stable for years and there are no known issues that need to be addressed — rebuilding just for the sake of using new technologies can actually be counter-productive. The new build with the exact same functionality is finally released after weeks of effort, but the code base is new — have all bugs been identified during QA?

8 UX vs UI

User Experience (UX) does not means great looking UI!

Great UX refers to the way that your users interact with your software and their experience throughout. This great UX must be applied throughout the entire user’s journey. You need to ask the following questions:

  • How does the user download or launch the product?
  • How does the user setup the product?
  • Are plugins or prerequisites needed?
  • Does the user need to refer to KBs or documentation?
  • How does the user license / pay / activate the product?
  • Are there extra prompts / warnings?
  • Is the product slow or using up too many resources?
  • Are all important options / navigation buttons visible when they need to be?
  • How do they contact support if needed?

As you can see from the questions above — we are not concerned with colour schemes, logos, styles and fonts. You can have great - looking software but if it is difficult to download and install / or it runs slowly for the user then you have poor UX.

The lesson to be learnt here is that we cannot confuse UI with UX. Good UI is just a subset of what is required to deliver great UX to our users.