6 Keys to Product Development

You've got the vision...what happens next?

The Vision

Imagine you have an idea for a product or service that is going to solve a major challenge that consumers, businesses or governments are facing.

You have a clear vision of what it is going to do, how it will solve the problem and how people are going to use it.

Now you need to build it.

You email a few software development companies, pitch your idea and then you’re off….your vision gets built, you launch, customers flock to it and you’re on your way to running a thriving and successful business!

Is it that easy though?  It should be….if your idea is good enough and you’ve articulated it well enough so that the company developing it knows exactly what you want.

The Reality

Why isn’t it so easy?

Well that’s because most entrepreneurs we meet aren’t able to articulate what they want in a language that developers can understand.  In fact, they’re often not able to articulate the idea in the exact same way twice.

What do I mean by that?  Well, I’ve met with many, many entrepreneurs and the one consistent thing I can point out is that each conversation I have with them about their product is different.

The idea they have grows and evolves over time and they very rarely spend time documenting clearly what they want initially, which means the ideas floating in their head at any moment in time are the most current but there’s no backdrop, no context to how they’ve come to the place they are at now.  When I talk with them, I’m expected to know all of the different iterations that have been running through their head.

The 6 Keys of Product Development

What do I do to solve this?  Well, I put them through our product development methodology that allows them to document where they are at now, what they are thinking about and we use that as the baseline for iterating through ideas and solutions.

Now, I will fully admit that the title of “6 Keys” is a bit of clickbait, however it is based on something I came up with years ago whilst working as the CTO for an e-commerce business in Norway that was very fast paced and had a great founder that was constantly full of ideas.

This methodology is based on the Zachman Framework I have just adapted over the past 15 years to fit start-ups and the entrepreneurial mindset.  It is a thought process that we at Atom CTO use to define the product that our start-up founders and business owners want to build and allows us to put things into simple terms that all developers, team leads, business analysts, software testers can understand.

The methodology can be broken down into 6 key elements that you need to define in order to provide a holistic view of the product or service.  Most importantly, this methodology is not just focused on product but on your business as a whole.

As I keep on saying: “An app is not a business”

The 6 key elements:

• Who?

• What?

• How?

• When?

• Where?

• Why?

  

Who?

Everything starts with “Who”: Who are your core customers, who will support your business, who will supply your business, who will engage with your business?

This is the first stage of product development and through it, what we need to understand is who are all the key stakeholders that will play a part in your business. This is not just about the customers but also about your employees, your suppliers, your partners and even to some extent your competitors.

The “who” also needs to be fairly specific. When you’re thinking about your customer, think about the different roles they may have. If it is a consumer are they all regular purchasers or will you have one offs or seasonal purchasers? If you are targeting a business, what different roles within the business are you targeting? Is there a difference in the way senior management will interact with your business as opposed to a factory worker?

When it comes to vendors and partners - what kind are they, what will they supply, how do you need to interact with them. For employees, how many do you have, what roles do they play, are they multi-tasking or do you have different people for different roles?

What?

Once you have defined who is interacting with your business and your products and services, you need to think about what the end goals and objectives for each of them are.

If you’re targeting a business, the goals for a worker on a factory floor may be different from the senior manager. The worker on the factory floor may be interacting with all aspects of your product or may need to be segregated from some areas whereas the senior manager may need to see data across all factories in all regions.

Similarly your employees, vendors and partners all need to have certain insights into your business and data in order to do their jobs well. Are you providing stock information to your vendors on a regular basis so they can replenish goods without you having to order them?  Do your customer service employees need to know about the purchases your customers make so that they know what level of service to provide - conversely do they need to know about people who raise many complaints?

The “what” is not just about what buttons people need to press to get to their end goal, it's about the data, the information they need in order to achieve their end goals in the most efficient manner possible.

How?

So now you know who is interacting with your business and what their objectives are, you now need to define how they’re going to do what they need to do.

This is all about putting down the business processes onto paper. How do different business units within your company act together with your customers, partners, vendors and other business units?

How does a customer actually buy from you? How do they get support? How does a vendor get the information they need to make the right deliveries to you?

You are designing the “value chains” within the business.  These are the sets of actions that people will perform that will bring value to them and your business.

But don’t forget to plan for failure. Not everything goes right 100% of the time. When you define your process flows, you need to also define what happens if certain parts of the flow aren’t met.

What happens if a customer doesn’t register successfully? What happens if a shopping cart is left abandoned, what happens if a customer says they haven’t received their goods?  What happens if the internet goes down on a factory floor.

You can’t cover all scenarios but you can plan for those that will cause your business to lose money or will cause dissatisfaction within your client or partner base.

When?

Not all actions will be performed by all of your stakeholders at the same time.  Based on the different processes / value chains you’ve created, identify when different stakeholders will be performing those actions.

This feeds a lot into design. If there are important tasks that are not performed frequently i.e. downloading an invoice, then these may need to be signposted clearly so customers don’t get frustrated when trying to perform the action.

Conversely, you may want to make it harder for customers to do things that you don’t want them to do, because they cause additional workload for you or hurt your bottom line.

Knowing when stakeholders will do things also helps you plan your resources better, you’ll know when to shift staff around or have more people working on certain tasks.

Where?

This is an often overlooked but extremely important question.  “Where” dictates many things - compliance and regulatory, language, connectivity and a lot of the non-functional aspects of the business that people tend to overlook at the early stages.

Your company may be selling goods in one country and delivering to another, so what do you need to know about the local laws governing that in both places?

Even if we don’t look at compliance, the “where” gives us practical insights - if your customers are going to be accessing your product on a construction site in the middle of nowhere, then you’d better be thinking about how your product will work with little or no internet.

The “where” helps you understand better the context in which your product will be used and what infrastructure and oversight you will need to put in place to support it.

Why?

This is the most important question.

When there are so many products and services to choose from, why should anyone use yours?

Do you have the best selection of products, are you the cheapest, do you have the best product support, do you have the only solution that is compliant and works in a certain jurisdiction?

The why is what shapes everything else within your business. If it is because you are the most efficient then you need to make sure that you design the “how” to be the most efficient. The “why” is the reason your business thrives or dies and when you have decided on the why, you need to go back through everything else you have defined and make sure that the “why” is ingrained into every step.

Job Done…

The 6 keys are not small, it is not a simple exercise to go through but if you want to build a product that will succeed in the long term, you need to go through every single step and make sure you fully outline the requirements for each.  At the end of it you will have a clear picture of your business that developers, customers and investors will all understand.

If you'd like to learn more, visit our website or listen to a LinkedIn live webinar where we describe the challenges non-technical founders face when managing projects and also provide some advice on what you can do to prevent those challenges from arising.

If you are currently facing a tech challenge or just want to have a chat, you can reach out to me via LinkedIn, via our Atom CTO page or just contact us.