Category: Product

In this post, I touch on the problem of blurring a product by giving too many priorities at once. The lack of a strategy and a consistently implemented plan ends up with an excessive fragmentation of the product. It is also important how we approach the measures. First things first.

What is priority

The word priority entered English in the 15th century. For several hundred years it functioned in a single form. It meant the first, most important, or previous thing. It wasn’t until the 1900s that we added the plural of this term and started talking about priorities.

At the beginning of this century, the word singular priority is used less and less. After all, it is so important that we want to achieve multi-level success, to do several things at the same time. Both in the personal sphere and with our product. But multi-level success cannot be realized in several directions at once. It is also worth noting that the word success occurs rather in the singular.

Kanban has a limit of “In progress”

I do not know if you remember yet, but in the kanban boards there is such functionality as the limit of “In progress” ticks. Yes – a long time ago it was turned on by default in task management tools. Now it’s optional. Multitasking rules. But are you sure?

There’s a hell of a lot of research into how multitasking kills productivity. It applies to both the work of an individual. But it is also transferred to the image of the product. The product should implement a correctly defined strategy.

One priority is not stagnation

For clarity. The product can be developed in several directions at the same time. Of course, but sooner or later these directions or features will begin to intersect. Then priority should enter on a white horse.

Priority should be engraved in the minds of those responsible for the product. If you’ve read my previous entries, you know that everyone is responsible for the product. So everyone should know what we are doing. Where are we going and when a certain stage of the journey will be completed. Like the three wise men going to Bethlehem. With this lame metaphor, we move on to the next aspect:

North Star Metric – one metric to rule them all.

The product must be measured. From the beginning to the end. How else to define success? There can be several dozen records. But it’s worth finding this one. One to rule them all, One to find them all. There is such a metric. There is also a simple framework as we want to make it. North Star Metric.

I do not want to elaborate on this topic. Smarter than me did it much better, for example here. I mention this metric because this is the fucking compass for your product. Which should always indicate priority. One priority.

Essentialism at the end

Develop a strategy. Set a metric. Set a Priority, one priority, and stick to it. Sure, you can do anything hurrrra, but how long will you ride that cart before you crush yourself. Essentialism isn’t just a brilliant way to arrange your life. It is also a great framework for a product strategy. But more on that later. 🙂

The first implementation is not the main topic of this post. It is also important what happens with the product after the first implementation. Often nothing happens. But it’s impossible to write about development without a few words about first entering the market.

Viable vs Lovable vs Marketable

A minimalist approach to product implementation is nothing new. In recent years, many approaches have been manifested in the IT industry: MVP, MLP, MMP (respectively: Viable, Lovable, Marketable.) A lot has been written about the pros and cons of these solutions. I will not be revealing here if I write that MLP is the best solution. For the client and for the company. It’s better if 10 people love your product than 1000 people like it. Building and implementing such a product is pure pleasure (at least in theory :). If you have real deadlines and latched business requirements, you want to work. I will write about the remaining 95% of the cases elsewhere.

Do not move!

Each of the stakeholders has a vision of the product. The more people, the harder it is to make a decision. Something has to be changed – everyone agrees here. The direction is clear – almost everyone agrees here. Objective? Here, opinions are increasingly divided. Instead of starting to implement something in small steps, we stand still and think about the utopian vision of the product, which most often has not been clarified yet. Fear of implementation and taking responsibility for changes can sometimes paralyze the entire team. At this point, the Product Owner should come in all in white and say

“Let’s check it”

Research, data, customer feedback – these are things that should be constantly monitored. Based on no changes made. Since we have feedback that something is not working, we should fix it. Let’s check solution B, it won’t get any worse. What we want to implement is not perfect and (sic!) We will not find a golden mean by standing still. A / B testing is an ideal solution. In other cases, you just have to implement, observe and react. There is no other way out.

Better to apologize than to ask

Someone has to hit the table and push this monolith forward. Otherwise the product will rust, you will start looking for the blame. It’s hard. You know what needs to be done, just don’t be afraid to communicate it. Market requirements and customer expectations are changing. The product must be developed. Step by step. Better to start a lopsided fight than suddenly try to breakdance and end up in a cast. 🙂

Almost from the beginning of writing articles on this blog, I try to prove that we are all responsible for the User Experience of our products. No matter what position we work in. He stands by the sentence, however, there is one distortion I would like to write about.

Responsibility is not the same as knowledge

Do you feel responsible? Cool! Do you pay attention to the client’s needs, do you remember his problems? You are my hero. Where is the problem? Often, problems require more analysis, research, and not making decisions on the go. Leave it to the specialists. If you are (dis) comfortable working with a UX Designer, let him do his job.

User Experience is like playing the piano

Everyone knows how to play the basic melody, but that doesn’t mean that they can get a job as a philharmonic pianist. I don’t remember whose comparison it is, but it perfectly captures the essence of the problem it is writing about. What is the base tune? It depends on the position you are working on. For the frontend, these will be the rules of accessibility, building forms, etc. For the Product Owner, it will be an exit to functionality from the customer’s needs, etc. etc.

When to consult a specialist?

The more questions, the less doubts. Lack of communication is a downside to IT projects. Inform as soon as possible what you do and how you want to approach it. What doubts do you have. Let UX Designer assess whether you have taken the right direction or whether it requires a different approach that you (I hope) will develop together.

UX for four hands

You should remember about the client and his problems. UX Designer should know it inside out. Coming back to the piano metaphor. Learning to play the piano also takes place with four hands at a certain stage. If you have the opportunity to work with a teacher, take advantage of it. You don’t want UX Designer to mess with your code or mess with your sprint. It is clear. UX Designer does the same.

Let us not go to extremes

UX ignorance is a big problem in IT. This has been changing recently. However, let’s not go to extremes. We can’t all shape our clients’ experiences, because that’s not the point. Where is the golden mean? Somewhere between “Where to add this button?” a “I added a new functionality because I like it”. The more you talk to the UX Designer, the sooner you will find the golden mean and everyone will be able to work in their area. With respect for the work of their colleagues.

This post will be a bit different from the others. There will be a lot about UX and product manufacturing, but that’s not the point of this post. More settlement and sharing of experiences of how I have fucked up spectacularly several times. But to the shore. The record below is more emotional than chronological.

Idea

We all know that a good product should solve user problems. I found three groups of users that solve each other’s problems. But what’s the matter? You are playing online. The advertiser pays for charity. User helps by playing. Non-governmental organization (NGO) gains a new fundraising channel. The advertiser gets a channel to reach the user who wants to view the ads. Everyone gains. Win – Win – Win.

Genesis

The idea was born on the microblog of the excavation somewhere between the first and second grain scandal. Offline I supported several non-governmental organizations as a volunteer. On the other hand, while working with clients, I knew what the problem was with reaching the recipient with the advertisement (ad blocks, etc.). During the excavation I found out that “there are more people of good will” they only need a tool.

First steps – first mistakes

I shared my idea on a microblog. The #GCH topic was also warmly received outside the excavation. I knew I was going in the right direction. Many people declared their willingness to cooperate. And here I made my first mistake. I was unable to translate these declarations into real help. Some people became discouraged, some were unable to give me specific help, and some of the enthusiasm subsided. At the next stages of the project, other people expressed their willingness to support, but I was totally unable to translate it into an effect. On the other hand, a few people saw it as an opportunity to earn money – fortunately, I cut myself off relatively quickly. I signed the project with my name. I knew he had to stay clean and clear from start to finish.

Tip of the iceberg

It’s a long way from idea to implementation. But here, for the first time, I found out that you need to start talking to programmers as soon as possible. At first glance, it was just embedding the game under an advertising banner. And only until. Protection against bots, monetization, captche, varnishe etc. I totally ignored it. I focused on UX and interfaces, forgetting about the real approach to implementation.

Competitions, grants, sponsors

With the project, I was a finalist of several grant competitions. I have spoken with some potential partners. And nothing. I heard everywhere that I should have long-validated MVP. Everyone mistakenly perceived the project as a mere embedding of the game and the banner. I couldn’t get them out of error.

Mock-ups, tests, prototypes

Work on the functionality of the project – this is probably the only area in which I have nothing to complain about. I rewrote and tested the homepage design from scratch several times. Additionally, consultations, surveys and observations. I will describe this case study another time. I have devoted a lot of attention to this area. unfortunately at the expense of others.

Nothing comes for free

I have stopped counting on grants, on an investor who will fall from the sky. After a few talks with my wife, we decided to finance the first stage of the project out of our own pocket. And then? and then you will see 🙂 This is how #GryCharytniczych is materialized in the version that I can subscribe to after more than 4 years.

What have I learned?

Cut down on functionalities wherever possible, but there comes a point where you can’t take shortcuts to everything. Talk to programmers from the beginning. From the beginning. I know that we are in the 21st century and everything can be done, but you need to be aware of the size of your venture as soon as possible. Choose your team assertively. Better to have 3 people who know what they are doing than 6 “ready to act”.

What’s next?

We validate the MVP. Ultimately, it is to be an open platform for NGOs, Businesses and Game Producers. Mobile applications, browser plug. Miracles wreaths. But it used to be. Or maybe it turns out that I have made a mistake in assumptions? We’ll see. For now, I want to test production my assumption, which was born a few years ago on the portal with funny pictures.

PSD2 is launched on days. Such an EU regulation that will require many changes in the banking and fintech sectors. The main change that customers will notice will be double authentication (2FA). These changes reminded me of one important thing that not everyone in IT is aware of.

Nobody wants to log into your site

Seriously. Logging in is never an end in itself. It’s just an obstacle to achieving your goal. Like any form. The client comes to you to solve his problem. Forms and interfaces only mediate this. They should be as unnoticeable and intuitive as possible.

Problem and solution

The service consists of actions taken to deliver specific benefits or meet needs (behind Wikipedia). Remember that. The service in itself is not and should not be the goal. Your software doesn’t work until it helps you with real problem-solving.

“Kill them all! Kill them all!” God will recognize his own”

Remove all obstacles, all forms, inputs, checkboxes, radios. Now put only those necessary to solve the problem. Put each one down carefully. See it as the Lego pieces that you throw around in the sauna. Every one hurts. Is subscribing to the newsletter in the finalization window really the right place?

The end does not justify the means

The goal is to solve the problem. Make every effort to minimize the costs that the customer must incur. The form, unnecessary functionality, too extensive options – all these blur the path to the goal. The customer is wasting time. He will go to the competition that does not bother him with products. The slogan “Time is money” is no longer metaphorical

We are abusing Primary Buttons. We, the IT industry. It doesn’t matter if you are a programmer, PO, PM or designer. Think three times before using the main button. By styling the linking on the screen, we can help or hinder the user. First things first.

Button for Button

When designing / implementing the screen, you have several forms of linking at your disposal. The most common are two buttons (primary and secondary) and a label. Depending on the style you work with, they can be named differently. Each button should visually have different states (default, hover, disable, etc), but you probably already know that. Let’s focus on their default state.

Click me!

Depending on the screen, each button / link more or less draws the user’s attention. It is by pushing individual links that lead the user by the hand through the confusing paths of our interfaces. If we start using the primary button everywhere, the user will not only be confused, but may also lose the track he was following.

Primary, which is what

The primary button is the main button. We use it to visually emphasize some action that we care about. To draw attention to an action on a form or to highlight the strongest call to action on a page. When not to use? In all other cases. The default button type should be Secondary. There is a reason why, in some design systems, Secondary is referred to as default.

Too many links, too many possibilities

I already wrote about the nonsense that the user does not like to click. This myth has long been debunked. The user doesn’t like to wonder where to click. The more buttons, the longer he’ll think. I am speaking here in the context of all forms of linking. Hide unnecessary links, use others / advanced options. Combine. Clean screens. The less functionality in one view, the better

The leader among buttons

It pushes itself to the fore at the expense of other interface elements. You need to separate the primusas from each other. The Primary Button should only appear once on the screen. Most importantly: not every screen needs a home button. Secondary is our default button from today. It would also be cool if we avoided the bar as such in general. We do not always have influence on this. Let’s focus on what we can change.

For the second time, I disassemble the UX myth into its first parts. The first was the click limit, and I hope you realize that there is no such thing as “The fewer clicks the better.” I was wondering for a long time what to take on the wallpaper second. The last weeks of cooperation with developers have dispelled my doubts. “I know the users (…) they need it (…) they will use this functionality …. “

No – you are not like your users

You know the product, you know business and developer solutions. Something that is natural for you – not necessarily for your customers. You float through the product interfaces like a lion in the savannah. Another functionality is ok for you. After all, thanks to this, the customer will save a few clicks, or will not have to go to another screen … But, does the user really need it? Are we solving the client’s problem or are we just adding another switch that no one will use.

Since you are reading this, I assume that you have been in the IT industry for a long time. You can install printer drivers or reinstall windows. You are the priest of the technology hearth and your mother asks you to configure a new phone. Congratulations! You are among the 15% of computer users who simply understand interfaces.

Solve customer problems, not yours

I wrote about it, among others describing the flow of UX Designer work, but it is worth recording it. Each functionality should solve the client’s problem. Before you evaluate your solution proposal, think by accident if you are trying to solve a business or development problem at the expense of the user. Does he really need this solution? Will he use it? Does he need it? Will this feature complicate our product? Remember – there is no such thing that the more functionalities the better. On the contrary.

Research and Data – this is a determinant of change

I may surprise you, but UX Designer doesn’t know the user either. Until I get data or research, it’s like humming copper. Yes, we can rely on good practices, benchmarks and competition analysis. But these are only half measures. As a Designer, I think this solution is cool. It corresponds to the needs of the business, but whether it is what our clients need, I will be able to answer only after testing and on the basis of data.

Let us learn from the mistakes of others

Do you remember Google Buzz? Tested by 20,000 google employees. A total flop. These were just not the target users. And no matter how much we want, we don’t know our customers. If you do not understand this argument, consider whether you can bet that your proposal will work? Half your salary? Exactly… One more thing: Your colleague from the desk next door is not a user either. He’s just nice.

As soon as possible. The following entry is for people who avoid testing for various reasons. The tests can be carried out independently and do not require large resources and skills. I encourage developers and analysts (product owners) to test their solutions. However, there are a few rules to keep in mind:

I am not the same as the client

Very often I come across the statement that in my opinion this functionality is ok. Apart from the anecdotal “It works for me”, we are not subjective. We know the product and probably from websites that our customers have not even heard of.

A colleague is not a customer

The fact that the colleague from the desk next to him likes your solution does not mean that customers will like it. Why? He probably knows the product, isn’t assertive, or just wants to be nice.

You are working in the production of digital products. Both you and your colleague are most likely in the group of a dozen or so percent, which we call the so-called Hard Userami. So you can handle any interface, no matter how complicated. (you are probably also responsible for installing the printer for your parents 🙂 Ok, since we rejected you and your friends from work from the tests, then

Who to test on?

Know your target audience. If you do not work with a specialized software, then this group is probably so wide that you will surely find someone who signs in among your friends. You don’t need a lab and some amazing software. Testing in the “natural environment” is much friendlier for both you and the user.

What to test?

As for the tool, you have total freedom. I recommend paper tests 🙂 You can sketch a simplified diagram or print another screens. Your choice. You can make a basic prototype for mobile from the Marvel application (easy to use). If you have some time, put a simple prototype in Invision. Both tools are free.

How to test?

Choose the basic problem that your product solves. Determine what screens are necessary to test your solution. Create a story that your friend has to do. For example, “Register on my site”. Prepare the screens that are needed to complete this scenario (see above). And watch.

If you have a paper prototype, you must describe what is happening and replace the pages. Watch where the user is hesitating. Do not stop testing. Let him finish, then ask why and where he had doubts. Were all the names and elements intuitive to him? Maybe he would change something? There are a lot of questions. Just talk about the project after completing the tests. If you have such an opportunity, record it. There is a lot of free recording software.

Why test?

Five users will find 80% of the problems with your product. Remember that. Already after the first tests you will see that the opinion of an outsider is worth its weight in gold. It’s nice if you have planted a testing culture in your organization. The return is irrefutable.

I know it is not easy. I once wrote about the fact that sometimes it is better to hand over the project without testing than to allow arbitrariness to arise. Which does not change the fact that you can also test (and have to) after implementation.

The following post inspired by an interview with Wojtek Kutyła 🙂

We all remember about the user. At least we try. His experience affects how he perceives our product or recommends us to his friends. We try to eliminate his problems and make it easier for him to use our products. But sometimes we miss the most important …

The user uses our products. But most importantly – this is our client. A person who wants to leave some of their money with us. We are all aware of this and this is only a name, but it changes the importance of the problem. We can ignore the user’s problems (sic!) But it’s hard to pass by when we see

Customer problems

As at the website level, we can still talk about a potential customer, inside our system we already have people determined to conclude a contract with us – a transaction. Similar to the behavior in the store: at the beginning, we let customers look around and make their own decisions. We can make a subtle suggestion. But when the client is determined to conclude a transaction, we must remember to eliminate his irritation at every step. We have to make the “purchasing process as easy as possible for him.

Irritated customer

We do not have a monopoly on a given service. The irritated client is unlikely to come back to us. As a result – we lose money, profit. There is also a risk that he will tell his friends about his irritation, which means that we also lose a potential profit. Of course. One customer does not make spring, but ignoring the customer’s problems in the long term will surely translate into our financial results.

Our client – our Lord (?)

Whether we like it or not – we should remember that customers are the foundation of our company. Let us not go to the extreme. Here it should be remembered that a single client cannot impose most solutions. Logical and rational analysis of comments. Systematic introduction of changes – to make life better for everyone. And remember that the user is the customer. With all the ramifications of this.

PS
I am not a supporter of the term “Client Experience” – I wrote about it once

Product Manager, Product Owner, Head of Product – positions rather known to people working in medium and large organizations. Competences more or less intertwine, everyone plays for one goal, somehow it was possible to live with it … Meanwhile, he appears on the horizon, all in white,

Product Leader

An enigmatic title appears on the Polish market: “Product Leader. How the best managers create excellent products and build effective teams (ebook) ”. The translator’s fault? Too. It seems to me that, however, the publisher knew the target of his publication well. We like it… those leads under the name on LinkedIn, these signatures in email footers, statuses on slacks… title fetishists. We are only missing the Product Coach, but I bet we won’t be waiting long.

Limits of competence

Everything’s fine. The more titles – the more blurred the competency boundary. The product is successful, there are handshakes, flowers, dwarfs dressed as Krakowiak. Everything fits together. But when the product goes down, suddenly the responsibility dissipates. Nobody gets up and says he’s Spartacus. What a pity …

Product Pope?

How many titles around the Product will we not build – there must be one responsible person. A captain who will go down with the ship and will be waving the bucket until the last moments. Someone who is not afraid to make the right decisions at the right time. Of course, I’m not here for some self-proclaimed coup or tyranny. A clear division of competences is fun and necessary… for everyone to live better.

You can also gather all these leaders, coaches, managers, heads in one place and lock them in a room until they choose one decision-making person. Let them announce their choice by exhaling white (ecological) smoke … Habemus Papam!

… and if it turned out that there are several popes, the Pole wins.