Do you like it? Part 3

After reading posts one and two, you already know that short term feedback easily discourages change. It's very unforgiving to anything that's different in general. But - the longer you've been working on your new product concept, the more you actually need short term feedback to move forward.

When you choose to expose people to your mind-bending innovation for the first time, you're obviously interested in problems they face. Those reasons are the real roadblocks between you and a succesfull consumer product - not the fact that it's different. The reason these roadblocks are hard to spot by designers and engineers building the product, is because the first impression is hard to simulate.

The work that has gone into your product, is founded on top of technologies, conventions and patterns introduced by products that came before it. This means that your user interface will send messages that work against your new ideas. Those messages are causing test subject's brain to spit out incorrect suggestions how to interact with it, making the product appear 'unintuitive'. The point of these quick feedback sessions is to identify and fix those characteristics sending bad signals, not to validate the design itself. The long term feedback is used for that.

Simply kicking out unwanted messages saves a boatload of time and money, because you're not adjusting the product concept to match those unwanted messages (that weren't supposed to be there in the first place). This protects the core breakthroughs and principles that originally encouraged people to turn it into reality, as well as invited others to buy it. Without the need to do large architectural changes, more effort can be invested to stability and feature completeness. Everyone wins.

Building products with entirely new qualities, that bring real value to end users (and force the competition to do the same), requires a lot of cage rattling. Great products will not happen on their own. It requires a lot of passion, courage and determination to help people transcend their previous experiences. You're building them a friendly and motivating passage through the fear of change.

And when you take people to places they didn't know existed, their emotional response to that will be beyond 'liking'.


Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

 

Do you like it? Part 2

The previous part introduced the problem of asking around for quick 'likes'. This post dives deeper into what makes the short term feedback so dangerous for new product development process.

The biggest challenge with short term feedback is how it forms. When people see or experience something for the first time (like your groundbreaking new product in this case), their brain is unconsciously trying to match that with any prior experience.

Time for a painfully accurate comparison: the human brain is like Microsoft's Office Assistant. It will suggest you things based on the information available to it. Irrelevant information will return irrelevant suggestion

Short test situations will give you plenty of data about dominant products that have been succesfully launched, but absolutely nothing to complete something that hasn't existed before. End users don't have the same vision that you have, nor have they used the product long enough for that vision to materialize.

Because people can't predict the future for you, they will be more than  happy  to  tell  you  about  their  color  preferences . Or about their hobbies, funny relatives and cute pets. You will hear why they like a certain font or type of food. Anything that comes to mind, really. Obviously, it's not their fault but yours. You're expecting answers they don't have; for problems they don't know. You might as well be interviewing lobsters. Or Clippy.

More tragically, you've just offloaded part of your product development responsibilities onto people paying your salary. Bravo, such a genious plan to escape later responsibility if things go sideways.

If you still think that one hour casual chat sessions with test subjects is all that it takes to validate new ideas and concepts, you leave me no other choice but to question your ability to read. Because this topic is not that hard to comprehend.

Everyone remotely familiar with studying user behavior are probably furious by now, and wish to point out that short term feedback can give useful insight, if you know how. That's why I saved it for the final part (when I get around to write it).


Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

 

Do you like it? Part 1

It's a well known wisdom, that asking early whether people like the groundbreaking product you're working on or not, has a tremendous potential.

Potential to destroy that said product, damage your brand, or even kill off your company; depending of its size.

Did that get your attention?

Good, because it should. The critical feedback in building new products (vs. copied), is the long term one. As the name implies, it takes longer to form compared to the short term one. People have to use your product for months instead of hours. There's no shortcuts, no silver bullets.

Quickly dashing around for likes, opinions, ideas and suggestions is an open invitation for a disaster. You're only chasing popularity and trends. Meanwhile, important values and product opportunities are drifting away - never to be seen or achieved again. It's a great way to inflict potentially irreversible damage to everyone in the value chain.

Alright, let's give that some time to sink in.

In the next part, I'll explain why short term feedback sucks.


Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

 

Good and bad software

I'm going to start with an argument.

Software exists because people are lazy; not that it's a bad thing. Throughout the history, it's been one of the greatest sources of ingenuity. A wonderful catalyst for ridding inefficiency.

It all started with a lazy person, defining a set of instructions for a machine, for it to do something people are bad at, and machines fantastic.

Those lines of code, running on a piece of hardware, helped that person to get more work done. Ideally, the time invested in instructing a machine to work for us, is far less in a long run compared to us doing all that work ourselves, impeded by human limitations.

Software exists to use computer's potential on tasks which people struggle with. People simply need to focus on instructing it. Sadly it's the focusing part where things usually take an unexpected turn from the ideal road. Right through the safety rail of professional training. Over and off the cliff of common sense. Straight into the bottomless pit of irrational. I visualized the problem below.

Given that a same amount of people, with equal skillsets, are working on a software project with identical goals, it's more likely that they end up with what I personally think as bad software.

Such software doesn't do what software is supposed to do. If you get stuck on the user interface part, you're missing the reason why people use your product. You have just instructed the machine to play hopscotch with the user, instead solving a user problem. The balance is just way off. Bad instructions, bad software. No amount of excuses change that.

Beautiful, well performing and behaving user interfaces can be built with relatively little amount of code, if you know what you're doing. If not, you easily end up with a complex and overdone interface; a monstrosity that needs even more complex customization options to tame -- or fire to kill, as it depends.

Still, game over.

Becoming blinded and trapped by the user interface iteration loop is very easy. It's the most visible thing for everyone in the project. That's why it's so important to be aware of this danger. Adding more interface easily feels like adding more value. How wrong can people be. You only waste resources on things that:

• end up eating even more resources since you're stuck with maintaining it
• restrict your options for potential devices and businesses in the long run
• distract user from the real value your product offers = less appealing product

"But Jaakko, isn't there many other areas as well that affect software goodness / badness?"

Yes. There are. A lot in fact. However, this one is something everyone can and should understand. It doesn't take a computer science PhD to figure this stuff out. It's especially important for companies whose business depends on software quality. Even more so with startups and small companies.

I'm going to end with an argument.

Your company exists because people are lazy. Make sure your product focuses on helping them, like a good software does.

 

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

What is keeping Sailfish OS alive

Image by Jolla

In my previous post, I used Windows phone as an example of how focusing too much on design can hurt your product. This post is a follow-up for it, focusing on the importance of design intentions and the overall reasons to do things in the first place.

Be realistically ambitiuos

For the sake of comparison, let's pretend that Jolla chose the strategy everyone expected it to choose: follow iOS and Android to join the mobile OS and smartphone business. Just close your eyes, and picture Jolla offering the same experience what Apple, Samsung and others already do.

Wonderful, here's the thing: that strategy has been perfected by Apple, Google (later Samsung et al.) since 2005. They will keep doing so in the future, without any intentions of slowing down. 7 years later Jolla was ready to compete against industry giants, with the announcement of Sailfish OS.

Enough pretending. Competing with this strategy, against these guys, is like trying to race against a bullet train, with a bicycle, without pedals. You will get nowhere; even if you pretend to. It's utterly silly to think you can beat them in their own game they've rigged beyond recovery.

You'll be spending all your time on things you can't compete with. And since everything you implement has a cost, it's more logical to find a simple solution for all those things that make your product a reality. Move through the mandatory feature list as fast as you can, so that you can save time and effort to use on what, in your vision, makes you relevant.

This is where Microsoft stumbled. WP tried to create value too close to competition, instead of building on top of and strengthening existing ones; those that made Microsoft relevant. In the end WP sabotaged Microsoft's opportunity to not limit its users to stationary computing. Their ambition to build a smartphone OS ended up instead limiting people also on the go. Looks like they're finally fixing this with Windows 10, so let's move on.

Be honest to what you exist for

Three years after the Windows phone launch, Sailfish OS rolled out as a very limited and rough experience. You were all set, if you had enough interest and patience to wade through tutorials, reviews and forum posts. It worked if you knew exactly what you were doing, but it didn't leave any room for user errors. There was hardly any guidance to help user. To be open about things, we shipped it with a beta stamp. Digital pioneers and average consumers alike received their copy, installed on the finest hardware we had access to; a mid-range phone on all accounts. A failure by industry standards.

But the thing is, we're not competing solely within industry standards; things what others already master. We have our minimal solutions for those, but our real business is where others cannot easily go. Either because they're too scared, lack the required vision, or don't really care as long as they can convince people buying their next wave of latest and greatest.

People deserve more natural and focused interfaces than current industry standards require. We need more openness, collaboration and sustainability =  a thorough value domain reset. Automation and computing in general are less about the technology, and more about finding a common direction to increase human potential; everyone deserves more time for things that are defining humanity.

What makes Jolla and Sailfish OS relevant, is our reasons to exist in the mobile space, and what our actions stand for in contrast to the competition. And that, ladies and gentlemen, is what keeps Sailfish OS alive. Not what it can directly offer, because it's not much at the moment. There's a mountain of work remaining -- actually -- make that two mountains; the operating system alone is not what you need for your computing tasks. It's merely a start.

We still need apps, more supported services and other natural functionality integration points. They are paramount in making sure Sailfish OS also stays relevant. There's a big functionality debt we owe our community. It's through their passion and trust, that we've given this chance to make a difference.

Respecting that debt would not only be human, but also an exception that this industry sorely needs to change.


Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

To evolve, or not to evolve?

That's not even a question.

Be it building shelters, gathering food or traveling long distances; people always had an innate desire to do things better and faster. It's been always possible to improve some part of an activity or a tool related to it. Even entire professions have been forgotten after becoming obsolete. Thanks to the increasing pace of technological advancements, our children won't anymore recognize objects their parents grew up with.

Except when it comes to user interfaces.

I grew up with computers around me, and my kids will grow up with even more computers around them. Over the years, they've gotten a lot smaller and immensely more powerful. What hasn't really changed, is the graphical user interface staring back at us. The desktop metaphor with windows, icons, menus and a pointer (WIMP) has stayed intact for over 40 years.

The first mobile devices had no touch screens, and had to be navigated with either directional keys or a scroll wheel. It was logical to use the same approach for such a miniaturized desktop, but when touch screens became more popular, user could directly interact with things. This made controlling a pointer redundant.

After the mouse pointer was removed and touchable things made a bit bigger for suitable finger operation, everything was ready for profit-making. Nobody seemed to question, whether an interface paradigm originally designed to be operated with a keyboard and mouse (WIMP), was really applicable for a mobile touch screen use:

Unlike desktops, mobile devices

• are primarily used without a supporting surface (table or similar)
• are used in dynamic environments with disruptions
• can't assume user is constantly looking at the screen
• can't assume both hands are available for a basic operation
• can't assume equal amount of time is available to perform a task

Regardless, all mainstream mobile operating systems treat mobile use the same way as desktop use. The familiar button-based navigation model, dating back 40 years, does not really qualify for mobile use. It requires too much attention from it's user to be efficient. Too much precision to be comfortable. Too much time to be fast.

Replacing mouse and keyboard with touch alone, just decreases the speed user can control the system, making it actually worse than the desktop. It's been a wobbly decade of mobile user interface infancy. The only way it's gotten any better, is through nicer visuals and smoother transitions. But that's just surface - a better hardware clad in finer clothes.

At this rate, my grandchildren can still identify an Android phone, because baby steps were considered good enough. That's a valid strategy as long as everyone copies one another, and no alternatives exist: a family tree that looks like a ladder. It's an open invitation for smaller companies to deliver less inbred products, that are designed to adapt to your life, instead the other way around.

If you still think those archaic desktop conventions are enough to keep your massive software business afloat today, you're not the first one. The bad news is, that the only way a dinosaur could avoid extinction, was to stop being one, and evolve into something else.

Before it was too late.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

Follow-up: Why the status bar has to go

My earlier post, about calling a persistent status bar a ghost of desktop days, got somewhat mixed reception. I was mainly talking about individual details, and forgot to summarize the big picture.

I'd like to take another swing at the topic from a less technical angle, by asking why do we own smartphones?

Everyone uses them to communicate with people important to them. We use them to consume content through any channels available. We all have slightly different ways we use them. Others take things further, while the rest settle for less. But everyone has one thing in common;  we all do it on the go.

We pay money to carry a piece of technology around all day, to do all these things when we want to. The value comes from the device enabling communication, access to information and entertainment. It exists so that we don't have to be tethered to our grampa's box all the time.

I don't understand why are we required to babysit our devices all day, using that small bar at the top of the screen?

When facing a critical error, all smartphones have that "I just soiled my pants" -look of a small child on their faces. But children are much easier to debug, because all issues are local. With cellular reception woes, the catastrophe can occur in places you don't even know that exists. You're only left with the stink.

We must stop traveling a road, where you have to keep one eye on the status bar and one on the content. We can't live under a constant fear of our devices jumping off a cliff the moment we're not able to see the status bar. It's a UX shot so wide, that you could park Jupiter with its moons between it, and the "smartphone" target you we're aiming at.

Making better products and better software is not easy, and will only happen gradually. Nobody makes software that behaves badly on purpose. It's bad because we, as users, are holding on to certain things extremely tight. We're constantly demanding more features on top of the old ones, without understanding the complexity it invites. Complexity in the software is the same for bugs, what blood in the water is for sharks. An open invitation to ruin your pool party.

That's why rebooting the smartphone value domain is important to see what is really needed.

Look at any, big, companies, that are throwing thousands after thousands of developers and testers at their software products, to keep the quality on an acceptable level. Even they struggle to keep the water safe for swimming. They're not bad at software, but their products are simply unwieldy.

And they're complex because we demand them to be. So make sure you demand only what you really need, because it will affect with who you're sharing your swimming pool?

Is it with people important to you? Or with bunch of f*cking sharks?

The decision is yours.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

Why the status bar has to go

The small black stripe at the top of the smartphone of your choice. Home for various tiny icons. Through subtle changes in them, we can decipher what's going on under the hood.

To better understand the status bar we have today, we must look at the desktop computing environment where the convention came from. The following image illustrates how different common desktop environments have solved the status bar. Top or bottom, (left or right. Always visible by default.

That design somehow felt like the only possible solution that anyone could ever come up with. Whenever someone started to design an operating system, they first drew that familiar bar across one of the display edges. Just like small kids default drawing the sun into one of the top paper corners. Only with the difference that kids move on, discovering other possibilities for sun placement.

Then came the advent of smartphones. Everything we got used to in the desktop environment, had to be crammed down to a smaller screen. So that we wouldn't mistake it as something else than a desktop </sarcasm>. A ceremonial bar was again crafted across the top screen edge, to give permanent residence for status icons. And after repeating that design pattern countless times, we should realize that the advent is now gone. It's no more, and here's some further incentive:

• As a digital medium, software is dynamic in nature. A fixed or static layout is more a design decision, not a requirement. Displays also exist for dynamic content, and suffer from static one. If you haven't yet heard about screen burn-in, well now you have.
• A small bar is a compromise in legibility. To not waste screen space, the bar height is kept tiny. This results in uncomfortably tiny icons. Some have made the bar automatically hide, to not distract user, but have still kept the bar and icons tiny. Sigh.
• Lack of structure and meaning. On a small bar, all icons compete with each other for user attention. Since everything is visible all the time, a subtle change in one icon is easy to miss. All icons appear visually equal in importance, even if they rarely are.
• Technical overhead. This concerns mostly app developers, but they're users as well. No discrimination, please. Better developer experiences are needed as well. Controlling status bar visibility and behavior is yet another thing to be mindful when creating your application. Also the OS owner has to maintain such complexity. Both sides lose.
• Lost screen estate. Even if little, it all adds up. It's not really a full screen if something is reserving a slice of what would otherwise belong to your app. There is a dedicated full-screen mode in Android, further increasing the technical overhead and complexity, for both app developers and system maintainers.
• Information overload and "over-notifying". We're bad at focusing on multiple things at the same time. Status bar at the top is screaming for attention and every time you take a glimpse at it, you need to refocus back to the whatever you did before. It's important information no doubt, but user decides when.

Even if mobile devices are almost identical to desktops as computer systems, smartphones are used in completely different way, than stationary desktops and laptops. Smartphone use is mainly happening in occasional brief bursts, instead of long sessions (desktop). User unlocks the device, goes into an app, locks it again and repeats.

It's important to understand that there's a reason for the user to do that. The device is not the center of your life, and is put aside all the time, just to be pulled out again when required.

And before the user reaches that app (or notification drawer/view), several opportunities present themselves to expose user to the system status without the need to make it persistently shown. Like making it part of the natural flow of things.

That is exactly what Sailfish OS does. It solves the aforementioned problem by showing important system information as part of the home screen content, resulting in:

• Dynamic screen usage, behavior designed for displays
• Superior legibility due to larger icons
• More meaningful icons are emphasized, more layout possibilities
• Less coding leads to faster app development
• Single behavior is simpler to maintain from the OS side
• All apps are full-screen by default
• Less clutter, information is showed on demand

Don't blindly embrace a legacy design as an absolute truth. Make sure you define first what is the problem it solves. Rapid advancements in both software technology and mobile context understanding, can provide you great insight in finding alternatives that didn't exist back then.

And keeping in mind that mobile != desktop will alone carry you a long way. Remember that natural interaction in mobile context needs solutions that desktop didn't have to solve. Use your head.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

What comes after applications

Over the past few years, there's been a lot of discussion over mobile apps: should there be apps or not? Obviously the question itself is an opinion divider. One side has faith in apps, while the opposition doesn't. This piece by Paul Adams from Intercom, was the latest manifestation I enjoyed. A good read for anyone interested about mobile computing.

This phenomenon is a result of people getting tired of eating the same app pill for every issue they have. The five year old marketing punchline "There's an app for that" really explains the dominant mentality. And with enough repetition, it was rooted deep into our minds. The emerged "app evolution" debate is just an indication, that people have finally become aware of the indoctrination. This post is my contribution to the topic.

Naturally, there's a gray area in between both extremes of the debate. To me, an application is just one of many ways to solve a user problem. When smartphones really kicked off the mobile app business, everyone wanted a piece of that pie. As a result, it became difficult to jump out from the app bandwagon. In addition to the "me too" factor, what makes an app so attractive option, is the degrees of freedom it offers to both the user and developer. However, it comes with a price tag.

Mobile operating systems have grown a lot since those days. They offer much wider range of tools to build engaging experiences. The common mistake is to think you need to implement everything yourself. Below, is my rough categorization of different methods a user problem can be solved; and how "less control" can in some cases increase the value compared to "more control". It's a matter of identifying the problem before finding a fitting solution for it.

• A background process takes care of performing the task in behalf of the user. It makes the solution feel like magic because user didn't do anything. As this requires an intimate knowledge of the lower software layers and contextual awareness, it's not really trivial to do. Not to mention being forbidden in many systems.
  
• A notification uses existing mechanisms in an operating system to promote a functionality or a piece of information based on its relevancy. This can result in genius solutions, since the needed functionality can be conveniently offered regardless of the context user is in. Even if there's not much interface work involved, a reliable context engine is hard to get right.
  
• A system integration takes a frequently used functionality and makes it an integral part of the operating system. This makes interacting with such a features much faster compared to an application counterpart. The result is a smarter and more holistic experience. However, this either requires rooting or OS ownership to do, so it's not an option for many.
  
• An application is the last step in the scale. Almost everything is possible here. It's very powerful and can be tailored to fit very specific tasks. Using an application as a solution easily adds more steps to achieving a desired result. Repeating these steps frequently to do something feels dumb. Due to the amount freedom it gives, and the amount of work is needed, the application experience is the most vulnerable to mistakes. Everyone can make an app, and it shows.

At the end of the day, it's about thoughtfully choosing and combining methods available to you. It's the next step in building mobile experiences. All these methods have their places in our daily throughput of tasks. So, even if apps are important, sticking with just them is a sure way to forfeit the experience game. Same goes for denying the application as a viable solution. Having a meaningful combination of variety is the key.

Because people are not binary by nature, so therefore solutions we use to respond to their needs must reflect that. There's no silver bullet, or a size that fits all. Using interaction variety in your user experience will make it more natural and approachable. Transitioning from app-focused model to user-focused model will give a reliable foothold in the market strongly profiled by features, hardware specifications and price competition. Finding other ways to create value is essential to differentiate and stay competitive.

The more you understand the platform you're designing for, the easier it is to deliver more natural and smarter experiences for its users.

Apps alone will definitely not be enough.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

What's the sand in your sandbox?

I was picking up my son from the daycare when I realized something. It took me for a round trip to the days I started at Jolla.

It was early July 2012. I was very excited about everything I had learned about the company over those few months preceding my hire. I was looking at non-hierarchical and self-organized group of talented people; teeming of can-do-attitude, and plenty of enthusiasm to match. With very lean ways of working, Jolla was about to play ball with the big guys. It felt amazing, and I was all game.

I'm a person who lives to do things. I love to study things by taking them apart. Every disassembled object has a story to tell, and those stories feed my obsession to learn and understand how everything works. When other kids at daycare played with their toys, I had a bag full of broken household appliances and power tools to disassemble. As a courtesy of my parents. Otherwise I would've taken apart something that actually worked, much to the horror of my daycare teacher.

Countless dismantled things later, Jolla was the perfect do-all-you-can buffet for me. It was very informal and open 24/7. Everything in that buffet was optimized for doing things together. So many things to take apart an learn from. We all had done mobile operating system work before. This time we just had to do it with a fraction of the manpower, without any hierarchy and management overhead. And the best way to do that, is getting your hands dirty with it. Explore, play, take stuff apart and and put back together. Don't be afraid of mistakes, instead love them for guiding you.

I realized Sailfish OS was the sand in my sandbox. Days on end, I went in to make sense out of things. It was important to work closely with developers, so there was just us and the sand. No matter how long it took, we would keep our hands deep in the sand. It was wonderful that nobody cared if I had sand all over me. Learning and understanding was more important.

I climbed out of my car and closed the door. My son was waiting me at the daycare gate with a big smile - all covered in sand. He doesn't mind the mess. Because it doesn't qualify as one for him. Instead it represents an exiting interaction; a freedom to do anything he wishes. It dawned on me that some people have learned to avoid getting sand on them. For those, I have a secret to share: you can unlearn it.

Learn to tolerate that the sand is messy. It's the purpose of the sand to be all over the place. It's up to you to mold and craft it to whatever you wish. No right or wrong way exist. The only rule there is: you can't make great products without getting sand on yourself. Your ability to do amazing things is only backed up by your relationship with the sand.

So take a look at your sandbox. Whatever it is that sand represents for you, get to know it again. Don't be afraid to get some of it on yourself. Take a look how kids do it. They don't see a mess. They see fun.

So should you. It's time to reconnect with the sand again, just like back in your childhood. Smile follows naturally.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

Responsible product development. Family style.

When creating something, you sign a responsibility pact.

By respecting that pact, your creation has all the potential in the world. Just like a child has.

The same parenting guideline applies equally for new products. You have already developed a deep understanding between your child, and it's your responsibility to make everyone understand and respect that. A small child cannot yet communicate that. Neither can a new product.

It doesn't matter how many of you there are, you're all mutual parents. The whole company is.

You all have valuable information related to the well-being and success of your child. If you share that information with new people becoming involved in your child's life, everyone greatly benefits from that. Especially your child.

The challenging part is, that most of the time, it's people you don't see. People in meetings you never attend. People in cities you never visit. People in companies you've never heard off. They all have expectations for that potential you've been meticulously nurturing.

Therefore it's important that everyone of you understands their role as a parent. All of those new external expectations can be perfect opportunities for your child.

Just remember to ask and also listen if your child wants to play hockey or piano. Break down those expectations to see how they fit the personality and traits of your child. Don't just blindly decide and demand something.

Because that breaks children, instead of helping them to grow. Don't expect opportunities to create a perfect child for you. That's just horribly wrong.

Treat those expectations as goals. Because they'll help your child to grow; to become stronger by overcoming challenges. However, it works only as long as it's the child who's overcoming them. Everyone else around is just a safety net, allowing graceful failing, and encouraging to retry. It's about honesty toward your child and ones potential.

If you solve a puzzle for your child, it's you who did it. No matter how hard you claim otherwise.

So don't make dishonest promises to anyone. Those just end up hurting both the growth of your child, and your role as a parent. Don't ask your child to skip elementary school in favor of dreaming about university.

People will understand if you openly explain your family values to them. What makes your child behave like one does. Also, if your child suffers from a permanent illness, it's only good if people involved are aware of it.

In the same way, every product has their shortcomings and weaknesses. Be open about them to others, and avoid planning the future on those weaknesses. A lifetime of failure will break children as well.

So remember to listen to your children.

Don't force them into being something they're not. Nobody benefits from that.

Because if you do, I sincerely hope that the responsibility pact in question was not signed in blood.

Our children deserve better.

Both in family life and product development.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.