Ask a business about their organization’s productivity, and they will talk about efficiency, collaboration, the importance of meetings or the value of async work.

The truth is, everyone has their own insights and frameworks around what makes them and their organizations productive. Sometimes it’s a really straightforward process. But most of the time, projects get bigger, teams get larger, and challenges get trickier.

The higher the complexity, the harder it is to define that thing we call ‘being productive’.

How to actually be productive when working in a team — the secret ingredients

If productivity is something you’re spending time thinking about, there’s probably a couple of things you’d like to see change. Things like:

• How do you make team members collaborate in a positive way, day in and day out?
• How do you facilitate productive conversations to figure things out, rather than let talks turn into endless circles?
• How do you make the small things no longer become big issues? Minor errors, things falling through the cracks — can you handle all the things that end up chipping away at team morale?

I’m going to assume you’ve already went through the steps of defining what you want to achieve, and your specific goals. You’ve probably already gotten strategies in place, and project plans written down. So I’m not going to talk about that part.

What I am going to talk about is the day-to-day stuff. The ‘I hate talking to [colleague name] because it’s always exhausting’. The ‘things fall through the cracks and we keep making mistakes’ part. The ‘why are we spending so much time on this uselessly’ part.

I don’t think sorting out these kinds of problems is hard, but it is dependent on two things:

1. You’re commited to not overcomplicating things, whether it’s processes, discussions, or project work. Say what you mean, and mean what you say.
2. You’ve got someone on the team willing to play the facilitator. In can be the team manager, it can be the project driver. It can even be that colleague that is good at summarizing talks and keeping things organized (no, it’s not the loudest, most extroverted person in the meeting. It’s usually the one who says ‘What I’m hearing is…’ and ‘Let’s agree on our next steps…’ ).

So, here are the 3 frameworks to make the day-to-day work less bumpy to get through

I’ve selected them after reflecting a bit on what are the most frequent tools I’m reaching for mentally, when organizing a group of people working on a specific project.

Here’s how to look at tasks, set up collaborations, and figure out what’s important.

1. Learn to think in flowcharts

You can use flowcharts to map pretty much anything you can break up into steps. You’ll usually find a flowchart when discussing user flows (how do I make a new feature for my SaaS product), process steps (how does an article get published on the blog) or sitemaps (how are all the pages connected).

Why learn this: it helps you break down anything into the specific steps to get from point A to point B.

Where is it useful: when you need to map application and site flows, process flows, information flows. When it’s important to not skip any steps (especially if you’re more of an intuitive worker and tend to do mental shortcuts). UX people are very good at this, go learn it from them.

When do you need it: when you get annoyed on the colleagues who worked on something before you because some point wasn’t covered or included. When things fall through the cracks and you can’t tell where.

Resources:

• https://www.nngroup.com/articles/wireflows/
• https://www.figma.com/resource-library/how-to-create-a-flow-chart/

2. Define roles with the RACI matrix

The RACI model — or the responsibility-assignment matrix is like a cheat sheet that tells everyone who’s doing what. It outlines the roles and responsibilities of team members based on their expertise, but also spells out the rules of engagement between team members.

• R — Responsible is the person (or multiple people) doing the work.
• A — Accountable is the person making the decisions, whether it’s about the direction you’re going in or signing off on deliverables. It’s healthy to have one person be accountable for one project, so things don’t get stuck in decision limbo.
• C — Consulted is how you define the stakeholders that have an impact on the project and their opinion needs to be taken into account.
• I — Informed is how you define the stakeholders that don’t have an influence on the running of the project, but who need to be informed of the going-ons to keep everything on track and avoid surprises.

In other words, when it comes to tasks, activities, or creating deliverables, the RACI matrix spells out what the team member’s jobs are, how to engage with each other and what expectations is realistic to have from each other.

Why learn this:

• it clarifies out loud who does what and who is responsible for what (from work to decisions).
• it’s a safe setup to difuse potential conflicts and have the difficult conversations around responsibilities and professional boundaries.
• It’s an elegant approach to let people bow out of responsibilies or communication flows where they can’t contribute much or which are not part of their scope.

Where is it useful: pretty much during any project kick-off discussion.

Teams that keep their members format will do this more formally a couple of times in the beginning, but soon enough the roles will become common knowledge and habit. It does help to do the occasional check-in, especially if the shape of projects change or new team members are joining.

Newly established teams or collaborations should always have this discussion.

When do you need it:

• when people feel they’ve been left out or brought in too late.
• when different people’s scopes overlap, and it creates friction.
• when you’re setting up a project with a large group and you need to clarify responsibilities and ‘rules of engagement’.

Resources:

• https://www.teamgantt.com/blog/raci-chart-definition-tips-and-example
• https://www.forbes.com/advisor/business/raci-chart/

3. Prioritize with the RICE model

Borrowed from product management, the RICE model helps you gauge how important it is to get something done and where it sits in your (probably endless) to-do list.

Let’s break it down:

• Reach: Imagine how many people will see your project within a specific time frame.
• Impact: Estimate the expected impact on your business. Think about both the cool numbers (like conversions) and the more fluffy parts (like customer happiness).
• Confidence: This one can be tricky: rate how sure you are that your project will have the expected reach and impact. You can base this on your experience, or on insights from what your competitors are doing.
• Effort: Eyeball how much elbow grease it’ll take to make the project happen. This in hours of people working on this and money being spent.

Why learn this: while you don’t need to always apply clear numerical values to what you’re comparing, it’s a useful shorthand to prioritise tasks and focus change requests or feedback on what’s most likely to affect impact and reach.

It can be important to do the actual calculations, to keep you grounded and make good assessments. For example, in situations like: how much money to invest in promoting each of your services, or how much budget to give to specific marketing tactics.

My rule of thumb is: Do actual calculations when getting it wrong carries great risk (for example, when you’re deciding budgets). Eyeball it if the risk is low (like when discussing feedback on a content asset).

Where it’s useful: whenever you need to prioritise a list of options. It can be the items on your to-do list, the choice of your marketing tactics, the next feature or service you’re releasing.

When do you need it:

• When conversations on tactics are stuck in decision limbo.
• When feedback sessions become an endless loop of comments and change requests.

Resources:

• https://fibery.io/blog/product-management/rice/

There you go, three frameworks to help you and your team be more productive.

Full disclosure: you don’t have to call out the framework you’re applying in a given moment. You don’t have to make it a formal discussion.

If you want to map a process, say ‘Let’s use stickers for what the specific steps are and how the project changes along the way. We can color code it for each team’s input.’

If you’re dividing responsibilities on a project, ask: ‘Who is the decision maker here? Who does what? Who gives what kind of feedback? Who do we need to keep updated on this topic?’

Don’t say ‘Let’s make a spreadsheet with a scoring system for each tactic’. Say ‘Let’s compare budgets and effort to outcomes from the past six months and prioritize from there.’

Does this really work?

You tell me.

Think back on experiences from your life, when projects and collaboration weren’t working out how you expected them. If you apply now one of these three frameworks to your situation, would it have gone differently?

Here’s what I’ve learned after 10 years of working in teams, in all kinds of different setups and companies.

Build the habit of covering the basics.

The more responsibilities we get assigned, the more we rise in the ranks, the more we tend to think that it’s the complexity that needs most of our attention. But it’s the basics that keep the wheels turning.

The proof of concept, the prototype and the MVP are three terms that are thrown around a lot in mobile product development. It’s no wonder it can be hard to figure out how to fit these methodologies into your product development plan.

It can take a while to understand the differences between them, especially if you’re a new startup or a brand exploring mobile-first products to expand your offering. So if you’re feeling confused, let me tell you it’s ok.

If you’re feeling confused, let me tell you it’s ok.

You’re deciding how to start building your product. At the same time, you’re looking at your budget and thinking about how to minimise costs. No one wants to make the wrong choice and realise they’ve thrown money out the window.

The TL;DR for what to make of a proof of concept, a prototype and an MVP

The most important thing you can do is keep moving forward, instead of being stuck in decision paralysis. Choosing how to start is something everyone had to do at some point.

No, really.

Every founder or intrapreneur that ever built a product started somehow. Even the ones that make the news headlines.

The short version for deciding between the three is this:

• The proof of concept (POC) method revolves around testing if an idea is doable from the technical side — in other words: can we make it work as we want it to, with the current technology and coding options available?
• A prototype of a product is a visualisation of it, meant to showcase the core user flows and help you identify usability flaws. It can be kept low-cost, or taken to full interaction levels, depending on what you’re looking to test
• A Minimum Viable Product (MVP) is the first live version of a product. It’s the core value proposition version wrapped in the essential features. It’s made to be launched as soon as possible to generate valuable user feedback and revenue.

The first thing to realise is that it’s not about choosing either the one or the other.

All three of these methodologies are used by product development teams to make informed decisions based on tested hypotheses. Using them saves money and brings to market a product that has the best chances of success.

This article was first published on Tapptitude on November 27, 2019. Read it here.

Let’s get to the bottom of a POC, a prototype, and an MVP

Next up, I’m going to walk you through the specifics of each of this method. Then, we’ll take a look at the pros and cons of each. If you’re in a hurry, scroll straight to the bottom.

If you’re in for the long read, here’s an outline so that you can scroll around.

The proof of concept (POC)

• When do you need to pursue a proof of concept
• Proof of concept helps you frame the development process

The prototype

• How many types of prototypes are there
• Prototypes are made to be shared and tested
• How is a prototype built

The MVP

• A useful, usable and delightful MVP
• How mini should your MVP be
• The business value of launching an MVP
• Do you always need to build an MVP

Let’s get started.

The proof of concept (POC) methodology

The proof of concept method is all about testing if a particular concept is feasible from a technical point of view. The process implies a project with a straightforward end goal. As a result, everyone should be able to answer the question: can this be built?

When do you need to pursue a proof of concept

Different aspects can influence when to pursue a proof of concept. The specifics of your product dictate them, and each helps you frame the concept you’re proofing. Here they are:

• Do you have a prototype created?
• Has your type of product been built before?
• Do you have competitors that offer specific, high complexity features? Is your product based on new technologies, like AR or AI?

Let’s take them one at a time and see why these matter.

Your prototype is ready for development

It’s rare for a product to be one feature and nothing much besides it. That’s why one part of the product definition process is to document and illustrate through a prototype all the features your product entails. When you have this done (we’ll enter into details on this in the next section), it’s worth taking the time to plan your development.

High-risk features that need more time coding and don’t have proven functionality should be tackled first, through a proof of concept process.

High-risk features that need more time coding and don’t have proven functionality should be tackled first, through a proof of concept process.

If your make-or-break feature isn’t doable, there’s little point in investing in the development of all the other functionalities of your product.

Instead, you’re saving yourself those costs. You also create for yourself a window of opportunity to pivot your product. Redirect your efforts towards a different take that generates value for your business and re-uses the proof of concept code in other ways.

Has someone done this before you?

If there’s nothing similar to your product on the market, then applying the proof of concept method is a must. It’s in your interest to ensure that your plans have practical potential in the real world, with real users.

We recommend proofing all innovative feature requests from our clients before planning out the whole project. You can even ask us to do a technical risk assessment of your product specifications, to make it easier to decide which features to proof first.

If someone has done these features before, there are comparable products on the market. In this case, there’s no point in testing features that have already proven their value. Which brings us to the next question:

Are your competitors doing this?

Knowing what’s out there comes hand in hand with understanding what your competition is doing.

Say you’re building a product in a market that already has several competitors (let’s be real, your product probably is in this category).

Your product will have similar functionalities with your competitors’, but you decide to take one feature and give it a distinctive edge. That is the kind of feature we recommend running through a proof of concept pilot. After all, we want your competitive advantage functionalities to work as expected.

Is your product built on new technologies?

New technologies — like augmented reality, artificial intelligence, or IoT — have reframed what people can achieve in their everyday lives. If your product has core features that are based on one of these new technologies, those are the features that need proofing.

Whether it’s an AR-powered mental health product or an automated transcription service, you want the core feature to meet the user’s expectations of what they’ll get.

Proof of concept helps you frame the development process

In all these cases, the proof of concept method enables you to frame how you look at the development process:

• it allows you to identify the high-risk features of your product and prioritise them
• it breaks down product development in simple yes/no pilot projects to test the technical viability of your product.

If the results for your proof of concept pilot are positive, you have even more motivation to pursue building your product and taking it to market.

But what happens if the results are negative?

What if we can’t build your core feature to perform as we imagined it? We have to be honest, that happens. Our imagination has always had faster legs than tech and software innovation.

Despite your expectations, a failed proof of concept isn’t a death toll. But it is a signal to pivot your product.

You may discover that the feature you’re testing isn’t as good as you wanted, but still decent enough.

Or you may find you need to scrap your approach entirely. Either way, you’ll be moving forward with your product. And making better-informed decisions than you had at the start of your journey counts as progress.

The prototype

If you’re looking for a way to start your product creation that pays more attention to the users’ needs, you need a prototype.

Prototyping is a tried and tested method of creating a new product and testing the waters with it before going full-in on development.

The concept is borrowed from manufacturing, back when you wanted to test the first version of a product — say a radio, or a chair, or a car — and get everyone’s buy-in to set up the production line.

In product development, a prototype is an interactive mockup of your product, built without a line of code. Platforms like InVision or Marvel help us bring together screen designs to create a ‘smoke and mirrors’ version of your product. A prototype responds to taps and imitates how a user inputs data, to give an almost real-life experience of your product.

Mind you, the process isn’t as simple as going from a blank page to a fancy prototype. Whether you’ve got a clear image of your product or just a fuzzy concept, it’s always easier to start prototyping with low-fidelity, low-resource iterations.

How many types of prototypes are there?

There are three types of prototypes you need to know about before you start designing one. Which kind you use depends on how much information you’re working with and what your end goal is.

Pen and paper prototype

A pen and paper prototype is precisely what the name suggests. Instead of reaching for digital tools, you stick to pen and paper to sketch out the first iterations of your product. If you’re working with a team, you’ll likely end up replacing the paper with a whiteboard.

Paper prototypes are a great way to:

• explore features
• replicate your competitors’ features to understand their building blocks
• align your team before starting the more in-depth work.

Low-fi, interactive prototype

A low-fidelity, interactive prototype — or a wireframe prototype — takes your product brief, or any paper prototypes you have on hand, and showcases your product’s features and flows.

It’s built without focus on colours, images, or illustrations and with a minimal emphasis on typography and icons. Instead, it focuses on functionalities and in-app copy to showcase how the product would work in a real-life situation.

Wireframe prototypes are great to visualise and review the functionalities of your product.

If you put it together in a prototyping tool, you can use it to gather early user feedback. You can check for things like:

• Do people understand the different actions they can take on each screen?
• Do people use the product as you intended?
• Is the copy clear and consistent everywhere?
• Do users find value in what the product offers?

If you’re getting contradicting or negative feedback on any of these points, you’re still early enough in the process to make changes with low costs.

High fidelity, interactive prototype

If you’re looking for the closest thing to reality, your goal is a high fidelity, interactive prototype. In this case, a UI designer takes the flows, features and structure visible in the wireframe prototype and brings them to life.

The designer decides on a colour palette and the building blocks of various elements. They add photography and consistent icons and designs each screen anew in technicolour.

They also decide on the micro-interactions and animations a person sees as feedback as they use the product. Buttons changing colours, cards whooshing open or close, screen swipes left or right, and many more, are all the domain of the interaction designer.

Prototypes are made to be shared and tested

Once you get this kind of prototype put together in Invision or Marvel, you have the equivalent of a cardboard Ferrari ready to take for a ride.

And by all means, do that.

Prototypes are most valuable when out in the world, getting poked and prodded by potential investors and future users.

The first will give you credit for your work and have a clearer image of what you want to build. In turn, this gives investors more incentive to finance you.

The second will be able to give you valuable feedback on how the product would help them (or not!).

Knowing how people interact with your product is very valuable in this stage. There’s still room to make changes, and they won’t cost you nearly as much as they would later on, once you develop the product.

How is a prototype built?

If you’re one of our clients, the process goes like this:

We start with a Product Definition Workshop, where we:

• outline your business and product goals
• help you position your product
• identify its audience
• map the product flows
• decide on the features we need to include.

Usually, we stick to pen and paper to visualise these flows and screens.

Then, we clean up the user flows and product map in digital diagrams, to have a clear picture of your product’s architecture.

A UX/UI designer takes this documentation and turns it into a wireframe prototype. Once the wireframe prototype goes through a round (or several) of feedback, it gets updated to a full-fledged high fidelity prototype.

This process takes between 4 to 8 weeks, depending on the product’s complexity. If you’re adding to it research time — for example, taking the wireframe prototype out for some testing — the timeline can extend.

You can choose to do your user testing with the wireframe or the high-fidelity prototype. Either way, it’s essential you acknowledge early that you will change your prototype based on user feedback.

A prototype is not meant to be pixel perfect. Instead, it should be capable of pointing out any errors regarding design or development early on.

Prototyping is another way in which you can save costs as well as generate new ideas regarding implementation. This is how we get to the third methodology of validating a product concept, the MVP.

The Minimum Viable Product (MVP)

Over and over again, we see in our work that there’s a general misconception about:

• What an MVP is
• When to consider building an MVP

This misconception goes somewhere along the lines of this idea:

In truth, an MVP should be more like this:

A useful, usable and delightful MVP

There are three levels to what makes a product successful. It’s a combination of how useful, usable, and delightful a product is. Let’s clarify those terms a bit, as they have a specific meaning in product design.

Useful means that I can use the product for the purpose for which it was designed. So whether I have a three-legged stool, a dining table chair, or a full-fledged office chair, I can use them all to sit down and write this article.

Usable refers to the ability of the product to be used in a simple and pleasurable way.

Sticking to the chair example, it would go like this: writing from the three-legged stool is doable, but about an hour later, I’d be feeling muscles in my back twinging. On the other hand, I can sit a couple of hours in a dining table chair caught up in the flow of writing. That makes it both useful and usable.

But if you want to keep me as a returning ‘user’, you’ll let me have the fancy office chair and feel delighted by it.

A great MVP will check boxes from all three levels: it’s going to be useful, usable, and delightful at a minimum level.

How mini should your MVP be?

When in doubt, go back to the basics. Trust the guy who defined the MVP in the first place, Eric Ries:

“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

An MVP is a basic, core-value-oriented form of your product, which you release into the market. Then, you watch and learn from the insights it generates about your target audience, as well as your business goals.

But what’s core-value-oriented when there’s an app for everything, and any respectable product has a mobile version?

Look at your competitors for insights

The answer to that lies in what your competitors are doing. If you’re building an on-demand delivery app, you should have something extra compared to DoorDash, FoodPanda, or Glovo.

If you’re building a productivity app, you’ve got to find yourself the niche that makes you stand apart from the likes of Fabulous or Evernote.

If you’re building a finance app, you should have something to stand out against the likes of Revolut or the Apple Card. Or, you know, move to a different market where you’re not competing directly against them.

What your competitors are doing is what sets the baseline.

Also look at what’s viable in the market

There are different ways to keep your MVP at minimum effort, but you can’t let it cut into what makes it viable in the market.

If your product can’t stand on its own well enough to warrant further investment, you need to pivot or approach the problem differently.

And here’s the neat part of these methodologies: if you’ve done your proof of concept on the trickier features, or gotten your prototype out to users early on, your experience with a live MVP will have better results than jumping straight in the water.

The business value of launching an MVP

If you’ve applied a proof of concept beforehand or prototyped your product, an MVP can help you focus on what really matters:

• are people actually using your product?

and

• can you make money with it to turn it into a business?

If your audience is resonating with your product, focus on understanding how that is happening and how you can make it better.

If you’re not getting baseline results in how users are acquired and their actual usage patterns, ask yourself why. It might mean you’re not targeting the right people, or it might mean your product isn’t offering enough value to their users.

Each case requires different actions to improve.

Do you always need to build an MVP?

If your product is very similar to existing mobile products, then grab all the knowledge you can from what others have already invested time and money into finding out.

As Eric Ries puts it, “we have to manage to learn something from our first product iteration”. If you can learn the lesson through other people’s experiences, there is no need to reinvent the wheel, is there?

However, the product concept does require an MVP, if:

• Your product demands a different behaviour from the user on a given matter
• The core value of the product is nothing new, but the UI is significantly different
• The development budget does not allow for more

Questions like:

• How many features should you include?
• How it should look like
• How long should it take to develop?

can be answered based on your context.

It’s exactly why we arrange a Product Discovery Workshop with all of our clients who come to us with a product idea.

When we do our due diligence to define and document your product from the start, we set the foundations for making better decisions in the future.

Proof of concept, prototype, MVP. Differences and takeaways

As you can tell, it’s your product concept and your context that dictates what you need when it comes to choosing between a proof of concept, a prototype, or an MVP.

There might even be cases when we’ll recommend doing at least two of the three before launching your product. Here’s an overview of the differences and takeaways of each, so you can make a better-informed decision.

At the end of the day, what matters is that you choose the path that helps you and your team make better-informed decisions.

While it’s important you don’t mistake any of these methods as replacements for what your product should be, remember that each can help you gain insights about your audience, the tech stack you need, and your business model. That, in turn, will help you save costs and set yourself up for as a successful product maker.

Tapptitude is a product studio specialised in helping funded startups and innovative brands to define, design, develop and grow mobile-first and interactive products that people love 🧡 to use.

If you’ve found this article helpful, make sure to check out Tapptitude’s blog here.

If you need help with starting your own product journey, we’re always happy to sit down with you for a talk. Contact us here.

Proof of concept vs Prototype vs MVP in app development was originally published in mobile appetite on Medium, where people are continuing the conversation by highlighting and responding to this story.