The core essens Martin spells out through out this book is pretty simple.

Change how you build - ship fast. Otherwise you wast time and learnings.
Change how you solve problems.
Change how you decide on what problem to solve.

Strategy = identifying what problem to solve
operations = solve the problem however you like

This is the product operating model that Marty argues is the way to organize to build great products

That’s the core message in five lines of text. (The book is better than my summary and still worth reading if you haven’t yet!)

Now, for my reflections.
Do you remember this little visualization of a process?

Yeah, me too. The good old Double Diamond.

I’ve lived this process for the past decade—in long projects, in PIs, in sprints, in design sprints, and in one-hour workshops. I’ve been running from left to right as a designer, as a product owner, and as a strategist. Exploring problems, pinpointing problems, writing “How Might We”s, exploring solutions, and drilling down solutions to a “low effort, high impact, winning, ship-it-fast” next thing.

I’ve come to realised something.

Being involved in both sides of this diamond works great in small autonomous product teams with few dependencies - Sort out what to do and do it.

It works very poorly in a big organisation.

With hundreds of product temas. Alignment is hard. When it comes to clarity around who is solving what problem and how close are we to actually solving it. Hundreds of teams running back and forth in these diamonds trying to convince each other what problems to solve. Some are exploring solutions to a problem that others solved.

This so called double Dimond Is often referred to as a way to describe a design process.

What if:

It’s also a way of describing a Product Operating Model - a way that all types of designers and product people already know by heart and preach, we just read it the wrong way.

Can we use this diamond to make sense of our organizational chart?


Instead of this:

We do this:

The important difference is Who is doing what tied to this model.

According to Marty Cagan, product leaders should serve the operations org with problems. Not just any problems—well-articulated problems that are critical for the business to solve, complete with a business case and an idea of what output we are aiming for.

The operations teams’ mission is to solve these problems.

This is a very simple way of describing a well-working product organization.

What if product leaders across an organization:

1. Agreed they all work in the problem space.

2. Agreed that their main mission is to define and prioritize problems.

3. Left the operations teams to solve these problems.

“Isn’t that what we’re doing?” you product leaders ask. well... I see a solution hidden in the direction defined by product leaders far too often.

• “Grow in this area” — It’s not a problem.

• “Improve customer experience” — It’s not a problem.

• “Have the best product on the market” — It’s not a problem.

• “Move this server to the cloud” — That is a solution, not a problem.

Operations teams have a very hard time acting on this. The result: they identify their own problems and try their best to tie them toward a strategic direction.

What if operations (product teams):

1. Agreed that they all work in the solution space.

2. Addressed defined problems with multiple solutions to decide on the best one themselves.

3. Left the problem space to product leaders.

My point is:

We all need to be super clear about who is working with strategy and who is operating. Who is within the problem space and who is within the solution space.

And what each side can expect from the other.

Maybe this good old diamond can help us illustrate that.

Keep shipping,

Gunnar

Subscribe now

Thanks for reading Always Be Shipping! Subscribe for free to receive new posts and support our work.

I went to a decent university and studied design methodology. It was a great program well-structured to ensure we all understood systems thinking, design thinking, service design, user research, interaction design, and even some hands-on programming.

Guess what 90% of my peers work with today?

They are UX designers. There is nothing wrong with that; it’s a great career.

But I’ve had a recurring thought lately:

In my world, facilitating the problem-solving process is design methodology. This is what designers know. This is what we’ve studied and earned our degrees in.

So, why are 90% of designers working at the very end of the problem-solving process, drawing the interface between a computer and a human?

Yes, the industry has had a high demand for people to create usable interfaces, as that is often part of the solution to a problem. However, that demand is rapidly decreasing. Things have changed. There are fewer opportunities out there - especially for junior designers.

It is becoming easier to put together usable interfaces. I certainly don’t think we should consume 90% of people trained in design methodology to do it. Maybe 10% is enough - someone to conduct actual user testing and tie everything together.

So, what about the rest of us?

“Ahhh! Where are you going with this? Should I go back to uni?”

No no no! - here comes the good part.

AI is here, and it brings a golden opportunity for designers to step away from interfaces and see the full system, a business, a service a product. We can finally work with what we always should have been doing: facilitating the process of problem-solving.

I believe this applies to both junior and senior designers. To be well-prepared for this shift, sharpening your facilitation skills and your service-design-toolbox is perhaps more important than learning how to prompt UIs.

At least, that is my wish for the industrial paradigm shift we are currently in the middle of.

Maybe we can all help explain this to those who still see designers merely as people who draw interfaces?

keep shipping,

Gunnar

Subscribe now

Yeah - it’s still free :)

I have released the AI-news aggregator https://signalbreak.ai/.

I used Lovable and Google Antigravity to vibe code, and Google Gemini-endpoints to build AI logic into the product.

New Year’s Eve 2016, Tokyo:

I’m jet-lagged, I just have arrived to a celebrating Tokyo, and quietly proud of myself for navigating the Tokyo metro without getting lost. Shibuya Crossing is pulsing, the countdown screens are warming up, and inside my pocket sits something that made the world feel strangely small:

BreakingNews.com.

I kept checking it between the neon signs and the crowds, earthquakes, political shifts, late-night developments. It was raw, immediate, and felt like having a global newsroom whispering into my hand. There were editors behind it, sure, but no algorithmic filter. Just the world, in real time.

I didn’t realise that this moment, this feeling, was about to disappear.

Why Breaking News Didn’t Make It

Breaking News looked like a product that should’ve survived the decade. It had:

• Millions of followers

• A highly engaged, high-trust audience

• A fast, clean mobile experience

• Editors who understood urgency

Yet NBC shut it down at the end of 2016, explaining that the business simply wasn’t sustainable.

If you zoom out, the problems become clearer:

1. A brilliant product with the wrong business model

Breaking News was designed for utility and speed, prioritising external sources over in-app engagement. This approach, while practical, resulted in high operating costs that were not sustainable under an ad-driven model. The team recognised that the app’s revenue generation was insufficient to cover these expenses.

2. Distribution shifted under their feet

By 2016, most people were already consuming news through platforms: social networks, phone lock screens, Apple News, Google Now. Breaking News had to fight giants for home screen real estate. And the giants were winning, mobile users overwhelmingly spent their time inside platform ecosystems, not dedicated news apps.

3. Automation arrived too late

Breaking News relied heavily on human editors for curation. It worked, but it didn’t scale. The company never reached a point where the cost of human-driven speed matched its revenue model.

So the problem wasn’t lack of love. It was lack of economic gravity.

Why the World Is Different Today

Since that night in Shibuya, the news ecosystem has changed in three fundamental ways.

1. News has become a background process

People no longer “go to” news, it comes to them.

Notifications, widgets, feeds, summaries, lock screens, smart assistants. The world pushes information at you now. But this shift also created alert fatigue: many users have turned off news notifications entirely because most alerts are noisy, irrelevant, or sensational.

The challenge today isn’t “send more alerts.”

It’s send only the ones that matter.

2. Platforms own the distribution layer

Google, Apple, Meta, and X increasingly intermediate news consumption. They’re adding AI-driven summaries, context boxes, answer experiences, and extracted article previews.

The aggregator layer, once thought to be a minor UX feature, is now a full strategic battleground.

3. Generative AI changed the economics

The biggest shift: the cost structure has inverted.

In 2016, to run a real-time newswire-like product, you needed:

• a newsroom

• a curation team

• a full editorial workflow

Today, AI can:

• read and summarise thousands of articles

• cluster them into coherent storylines

• extract what’s new, what changed, and what matters

• surface the essence of breaking events in real time

Apps like Particle, Volv, are already doing this at scale.

This doesn’t replace human judgment (and shouldn’t), but it dramatically reduces the mechanical workload, making an operation that once required a full team accessible to a far smaller one.

This is exactly where Breaking News was too early.

AI Changes the Game for a New Breaking News

So what does an AI-driven Breaking News 2.0 look like?

1. From isolated updates to narrative-level awareness

AI can group related updates into evolving storylines, something historically done manually by editors. Instead of dozens of standalone articles, users see:

• the central event

• the key updates

• the context

• what changed since last check

It transforms a firehose into a map.

2. Summaries that compress complexity without distortion

Speed matters, but clarity matters more. AI summarisation allows:

• real-time updates

• consistent structure

• fast comprehension

• links back to full sources for verification

This is perfect for breaking news, where users need signal, not noise. And critically: summarisation is now cheap.

3. Human-in-the-loop elevation

AI can do the clustering and compression.

Humans do judgment.

• What is worth an alert?

• What is actually breaking?

• What should be highlighted?

• What needs editorial caution?

Given how easily AI can hallucinate, sourcing, transparency, and editorial guardrails are more important than ever.

The best system is hybrid, fast where machines excel, trustworthy where humans intervene.

Why Product People Need to Go Full-Stack Now

I went full-stack on https://signalbreak.ai/

There’s a lot of conversation right now about how product managers must become more full-stack, not necessarily in the sense of building entire backends, but in understanding and operating across design, data, code, and rapid solution discovery.

Gunnar has written on Always Be Shipping about how AI changes the product role:

Someone once said, smart people with AI at hand will become even smarter. Less smart people with AI tools at hand will not come across as any smarter at all.

In other words:

• Knowing the customer problem is no longer rare.

• Knowing how to rapidly prototype, test, and iterate solutions is.

• Being able to work hands-on with AI tooling and pipelines is now part of the craft.

As AI collapses the cost of experimentation, the bottleneck moves to the PM’s ability to formulate, test, and refine end-to-end solutions.

I realised I couldn’t just observe that shift.

I needed to live it.

So I put my own skin in the game and started building an AI-driven news aggregator, not as a thought exercise, but as a real product. Touching the APIs, the clustering logic, the summarisation, the UX decisions, the editorial guardrails. Owning the loop.

It’s uncomfortable.

It’s exhilarating.

And it feels like the only honest way forward for a PM working in 2025.

Back to Shibuya — and Forward to Whatever’s Next

I still remember standing in Shibuya Crossing with Breaking News in my pocket, feeling the world narrowing into a tiny stream of signals. That experience lodged itself somewhere deep.

Breaking News shut down soon after.

The need it met never did.

Today the tooling finally exists to revisit that idea with:

• cheaper summarisation

• automated clustering

• hybrid editorial judgment

• a modern distribution environment

So this is the next iteration for me:

Taking that spark from 2016, rebuilding it with 2025 AI, and exploring whether there is a product-market fit this time for real-time, AI-supported, high-signal news.

Let’s see what I ship next.

Always be shipping 🧡
Alexander

Philosophical Question: Do we need to reinvent the design process now, when we can prompt a decent, workable UI faster than we can wireframe a poor one?

Well, the short answer is no. The longer answer is: Yes, it will never be the same again.

Reflection one - the golden era of ideas

Coding stuff is now cheap. For the first time since “hello world,” it’s actually cheaper to build digital products than it is to sort out what to build. We can now generate a ton of (soon-to-be) pretty workable code basically for free.

With a couple of Claude and Lovable tokens, a normally gifted person with a laptop is now your potential product team.

This is the main change I see coming:

Good ideas now beat execution muscle. Why? Because execution is no longer the critical bottleneck.

Imagine: The golden era of good ideas is finally here.

Reflection two - The UX/dev ratio

Good ideas on what to build are the new bottleneck. This is great news for anyone in the business field of identifying the right problem to solve.

Developers will soon need to hand over their superhero capes to service designers and researchers.

My working hypothesis is that resource allocation will need to shift this way within product teams.

The one normally gifted person as your new product team might maintain the same velocity as your previous team when it comes to pushing things to production.

However, sorting out what to build still needs to be done. So one developer working together with four designers is probably what a strong product team will look like in the future, rather than the other way around.

Reflection three - The new problem

Someone once said, smart people with AI at hand will become even smarter. Less smart people with AI tools at hand will not come across as any smarter at all.

It was me, I said that.

It’s quite easy to tell the difference between: “AI did the task for me,” and “I did the task, and AI helped me do it faster and better.”

Designers, listen up. This is the shift we’ve been waiting for, you now have the chance to make a real difference.

But you have to watch out. It’s very, very easy to fall into the trap of vibe-coding cool stuff in a linear process. These AI tools are addictive, like YouTube Shorts, so make sure to use them wisely.

And for goodness’ sake - stick to the process you already know. Start by identifying a problem; this is what makes you and your competence valuable - even more going forward.

When everyone can prompt out a product concept during their lunch break, the prompt that actually solves a real problem wins.

Reflection four - After you know your problem

The design process is not linear. It never was - and it never should be. You need to ideate a shitload of solutions to ensure you move forward with the least crappy one. Yes, that’s how it’s done.

With a tool like Lovable, it’s very easy to skip the divergent parts of the process and just go for the solutions your AI suggests. Don’t.

Make sure to do your Crazy Eights, miniature sketches, and Lightning Decision Jams. Do it together with our new AI friend, do it on a napkin, do it in a regular sprint. Just make sure you do it.

Reflection five - working in the same tool

The traditional product development cycle is in crisis - and perhaps it’s long overdue. I’m seeing a shift where product managers are now attempting to visualising an entire product by “vibe coding”- out the core concept from scratch alongside 15 key stakeholders in a single two-hour workshop.

What’s the potential value in this chaos?

Surprisingly, quite a lot.

The real strength lies in the power of direct collaboration within a single, simple visualization tool, one easy enough for anyone to immediately jump in and contribute to a concept. A way of understanding each other better. Pen and paper 2.0.

Just my humble reflections for now.

Keep shipping,
Over and out,

Gunnar

Always be shipping is a newsletter on digital product development that is shipped on a not so regular basis. If you liked this one make sure to get the next one right down your inbox.

Subscribe now

My feeling is that designers are quite happy people, happy with their tasks, not too stressed out about workload. They go to work with a smile, sit down to enjoy nerdy coffee while reading the four new emails from yesterday.

They plan a workshop for half a day and then open Figma to move a pixel or two while listening to cheap indie in expensive headphones. And for the record: I’m not saying this is, by any means, a bad way of working – quite the opposite, actually. I think that this is in many ways a healthy and sane way of coming closer to our shared goal: create value.

Quality takes time and design is a process that needs to be respected. Rushing = not doing design well. It seems like designers have it all figured out, it’s a role that has the fundamental ingredients of not rushing into crapy decisions. A key pillar in design work is to reflect and really motivate every pixel move with deep insights.

So what’s the problem then? - and what’s the learning? - I will get to my point very soon - I’ll just have to share my blunt generalising observations on what a day looks like for a product manager as well.

Product managers on the other hand - wake up early to catch up on the already overloaded inbox before the first meeting. Back to back meetings throughout the day, but there is an ongoing incident that needs to be coordinated during these meetings as well.

Decisions are asked to be taken in the chat and stakeholders are wondering about feature requests and performance data. With a long list of requests waiting to be prioritised and a team member who just resigned - it’s a pretty stressful day.

The very core of this role is to make sure the product team spends time on the right things. But with 20 great ideas and the capacity to take on one thing - it’s easy to feel something like “WE ARE NOT MOVING FAST ENOUGH!” With high expectations on what to deliver from different parts of the organisation - and with the goal to be as fast as possible to market, this is in many ways a role that has the basis and the fundamental ingredients of a stressful work situation.


I’ve now had the pleasant privilege to work both as a designer and a product manager. I've done the headphones and Figma, and I've also had a “crazy busy week” once or twice. I have been part of these two different communities and picked up some clues on how we together can become better product people, how we can tweak our ways of working together toward a more value-driven approach. I’m not saying I have figured it all out, but I think I have become a much better product person by having one foot in the design community and one foot in the product management community. Understanding both roles and the types of struggles we face in both design and product thinking helps.

Here are my humble lessons learned so far:

What designers can learn from product managers

Value is created only when customers interact with the design made. Only then can we see and measure the effect and move forward, make money, raise KPIs – measure OKR outcome. Meaning: The goal should be to release things. Always.

Figma and the workshops are tools to get closer to something that is releasable. But my feeling is that designers tend to spend quite a lot of time sorting out what to research, what to design, doing workshops on what to workshop on. Solving the right problem is important, maybe the most important. But as long as no release happens, no value is created. Let this sink in for a second: as long as no release happens, no value is created, since value is created only when customers interact with the design made.

So if designers could have release in mind, set goals around small releasable pieces of work, the world would be a better place, at least from a product manager’s point of view.

One insight and one release drive much more value than 1000 insights and no release. Design too often tends to be like 90% sorting out what to build and 10% making it actually happen. I think a 50/50 approach would bring a lot more value.

Designers could spend a little less time on visionary work and a little more time on getting things out – like story writing, story mapping, coordinating feasibility, connecting with stakeholders, QA. Small improvements – hand over a list of low-hanging fruit fixes to our PMs. Make release happen!

What product managers can learn from designers

first: Chill the crap down! You are not exactly creating value by sitting in meetings and being stressed out about things all day long either. Value is created first when you hit that go-live button – when users interact with the feature you made. Only then can revenue and happy customers happen.

So, take care of your time; one good decision is a lot better than 20 not-so-good decisions. Building great products takes time and needs reflection. Enjoy a nerdy coffee and some indie once in a while. Think about all the meetings as: Is this meeting bringing us closer to a release, yes or no? And set the priority based on that.

Product manager work tend to be 10% sorting out what to build and 90% trying to make this happen. I think a 50/50 approach would create much more value here as well. Meaning more: identify the problem, ideating on solutions, taking part in usability testing, writing surveys, and less coordination and overhead work. I think that this way, it’s easier for the product owner to identify the smallest releasable thing as well.

Now go ship something.

Happy Friday!

"Before my list of six tips—not in any particular order—on what can make the difference.

Workshops, on a more philosophical note: a forum where thoughts and feelings are cared for and listened to. Don’t underestimate this part; it’s actual human needs. And if everyone feels safe and comfortable sharing their thoughts and feels heard, we have a pretty good foundation for achieving great things together. Imagine if we all felt this after every meeting. yes Imagine!

Workshops are also outcome-oriented and democratic; ideas and decision-making can be made both fast and democratically with just one well-structured exercise. whaat? yes, it can.

Lastly, workshops are fun, and if we have fun, work is fun. And we keep coming back to it.

Selling done—now learnings:

01: Prepare attendees a day before

The workshop you are having tomorrow—and were invited to a month ago—isn’t exactly top of mind for your fellow coworkers. I usually send out a short, friendly reminder the day before. This includes a brief agenda and underlines why it’s important to participate and prepare everyone for an awesome event. This increases participant levels quite a lot. In times of hybrid working, I would say this is necessary to make people show up to an on-site workshop.

This message often results in people asking questions and getting the engagement going. And more importantly—showing up at the actual workshop!

02: Music is more than mood

I like to fill the room with a mood before the workshop starts—set the stage and move people out of their regular, busy-running-between-meetings persona. Music works great to tell people that we’re doing something else than the regular Monday meeting here. It can create this calm coffee shop vibe or spa feeling or even ‘Friday at 3 PM’ energy—whatever mood you’re looking for—Spotify’s got your back.

Plus, music is golden during focus time. When notes are written—when iframes are drawn—when ideas are… ideated. Music keeps everyone in the zone.

It also usually makes people shut up and focus on the task; if not, you can always drop the ‘music means silence’ rule.

03: Prep the room

You are probably familiar with the guy who likes to spend the first eight minutes of a meeting connecting cables, trying screen-sharing settings while also moving furniture around, mumbling curse words. Don’t be this guy please.

These first minutes are likely better spent on greeting everyone welcome and having them enjoy the elevator bossa nova your Spotify DJ gently plays in the background. To achieve this, you just have to book the conference room 15 minutes ahead in a separate booking. This way, you’ll have time to sort out the tech—hand out post-it notes and rearrange the furniture however you need without stealing time from your participants. You’ll also come across more like Leonardo DiCaprio at a cocktail party instead of George Costanza in a conference room when people arrive.

04: Names by heart

If you're running a workshop with people you don't know—remembering everyone's names is my nightmare. To combat this, I draw a super-simple, probably-not-to-scale map of the room on a post-it. Then, during the ‘introduce yourself round,’ I scribble down names. I have a better chance of actually learning the names, and I have a cheat sheet if my brain decides to forget anyway.

If no one knows each other, having everyone write their own name tag can be surprisingly effective.

If you all know each other—that's great! Maybe skip the ‘who are you?’ introductions and spend time learning something actually interesting about each other instead.

05: Format is important—but purpose is key

Whether you’re running a lightning decision jam or a design studio or trying to survive a full-blown design sprint, my take is: formats are more like guidelines than actual rules. They need a good ol' twist to match what you're trying to get done. I’ve tried a lot of different formats over the years, building a toolbox of exercises and sneaky tricks to pull from. I’m not afraid to create new formats and mock together workshops based on what outcome we are looking for. The purpose of the workshop is way more important than sticking to a strict format.

If you are new to running workshops, I recommend you try out a couple of standard formats and learn running them by heart. When you do, you will have plenty of thoughts on what might work and not in any given situation.

06: Feedback. Always.

Learning is never-ending, right? And even after running many workshops, I still have a lot to learn and improve with my workshops. Asking for feedback is one way of improving and learning over time. I usually build feedback into the actual workshop—to make sure it happens, and that everyone shares their experience with the workshop.

One way of doing it is to save five minutes for a last exercise with the group—have everyone write a note or two and leave it on the door as they leave. Ask for specific feedback if you have specific questions; ask for general feedback if you don’t know what to ask for.

-

Yeah, that’s what I pulled from my brain for now. I also thought about: time boxing, planning a workshop, remote, on-site, and hybrid setups, and dealing with people.

Maybe that makes up for a part two on the topic?

Keep shipping,

Gunnar

I have now listened to two-thirds of an audiobook about the Vasa ship, read a decent part of the Wikipedia page, and realized that I probably should pay the Vasa Museum a visit. So, I’m still no expert on the subject, but I can now, based on my research, confirm that the process of building the Vasa was pretty far from agile. In fact, the project method was so anti-agile that it stands as a perfect example of what we are trying our best to avoid by working agile. It’s such a great example that we should use it as a story when teaching agile. We should use this tale as words of wisdom when explaining design-driven product development to business stakeholders. It's a tale we should always keep in mind and heart, tell our juniors, put in our agile way of working sales pitch decks, tattoo on our forearms, and so on, to never forget: Why agile?

Here’s the tale.

Once upon a time, there was a king, Gustaf II Adolf, who was crowned at the age of sixteen and had since then spent most of his days fighting wars against pretty much every nation you can think of. If Gustaf II Adolf had his war stats written like a UFC fighter, it would look something like: W 30 - L 5 - D 2. He had turned Sweden into a great power, now knocking on the door of controlling Europe. In other words, not your average grumpy-high-maintenance-kind-of-stakeholder. This was a badass who knew just what he needed to win this ongoing war against his cousin Sigismund, king of Poland, who also considered himself to be rightfully entitled to the Swedish throne (yeah, it all sounds a lot like a certain HBO series). Gustaf II Adolf needed a battleship like no other, the kind of ship that makes the enemy quake in their boots before they resign, jump in the water, and swim home.

Henrik Hybertsson and his brother Arendt were just celebrating winning the noble and lucrative business contract of building this ship and a couple of other almost as expensive ships when they received the following requirement spec from Gustaf II Adolf:

• Must have 64 guns, both long and short cannons

• Must have two gun decks

• Must be <220ft long

• Must have a stern castle (it’s sort of this high balcony part at the end of the ship where Captain Hook hangs out)

Non-functional: Needs to showcase how awesome I am as a king and that God is with me on this journey of taking over the world.

400 years later, this set of requirements might sound like an average ship order detail spec from the past to your ears. But back then, it was seen as:

Henrik Hybertsson, who was highly regarded and reputable in the business of crafting warships, had already led projects building several well-served ships for the Swedish navy. He had some deserved confidence at the time and answered the king something like: "Dear King of Sweden, your spec is beyond the reason of what is possible to build." He tweaked the spec into something he, with all his knowledge and experience, thought would make a great ship and a happy customer but within the physical limits of what was considered possible to build at the time.

The king responded: "You will build the ship my way."

And with respect to the king, he answered, like every consulting firm afraid to lose a well-paying client would: "Let’s do it your way then."

At the time, public procurement was not really invented, but the contract they signed actually serves as a great example of how wrong this type of negotiation can go. Knowledge is foresight, and the explicit requirement list is what’s on the table to deliver on. The best price wins the deal, regardless of it being possible or not to deliver on, without room for expert advice. It’s funny we still put this method into practice in Sweden 400 years after we tried it for the first time, despite the memorable outcome. If you’re not familiar with Swedish public procurement, it usually ends up with very expensive hospitals or useless journal systems for 5,5 billion SEK or so. Or like in this case - a warship at the bottom of the sea.

At the time, ships had no blueprints—you sort of built them based on your experience and refined them by making small incremental changes upon the last ship you built. And yes, you heard "incremental," so this is where the argument of Vasa being built with an agile approach is born. It’s not a rock-solid argument, and I’ll come back to why. One problem with the design/requirement spec of Vasa was the combination of two decks of cannons plus the stern castle. This combination had never been done by Hybertsson before, and this was what he initially advised against.

The 300 craftsmen who worked on building this ship for two years without getting properly paid all realized along the way that this design would make a pretty wobbly warship. Gustaf II Adolf did not exactly have an HR department in place yet, and the union wasn’t invented until 200 years later, so if you wanted to keep your job and also your head attached to your body, you kept your mouth shut about questioning the stability of the ship.

You can probably imagine how toxic this chain of leadership was when no one dared to report their really valid concerns to upper management.

Hybertsson's stakeholder management skills may go down in history as poor. Or let’s call it a textbook example of what poor stakeholder management can lead to. But he was also sick and passed away during this project, and he took his game plan of how Vasa should be tested and refined during the process—and his experience and gut feeling—with him to his last resting place. So the new project manager finished Vasa by creating the missing pieces of the puzzle with his best guess of what he thought Hybertsson had in mind. Stressed out with letters from the King, who was writing to know: "IS IT DONE YET?!"

Turns out, a blueprint or some documentation might have come in handy after all. The ship’s ballast (heavy stones put in the hull of the ship to improve its stability) was already built into the ship, and it was way too small to make up for the 64 guns so high up on the ship to make it stable. The ship was unstable as a flagpole with cannons on top. And everyone knew. Even if it was possible to load more ballast onto Vasa, it would have made the lower cannon windows take in water as the ship was already very heavy—so the ship was badly engineered from the start and impossible to improve.

On the 10th of August 1638, Vasa was fully loaded and ready to conquer Poland. The captain of the ship commanded a stability test right before departure and had 30 men run back and forth across the deck from port to starboard. The test had to be aborted after just three runs, as Vasa was about to capsize at the harbor due to this test. "Phew! Thank God we called that off in time!" he said and later the same day sailed the ship right to the bottom of Mälaren, where it stayed for 333 years. The captain said in hearings that he wished the King had been there to see how unstable Vasa was during this test. What a test lead.

Imagine your product team doing a stress test of your latest feature in stage, aborting the test as the servers were about to catch fire—but you still push to production saying, "I wish the CEO could have seen how unstable this feature was before we released it." It’s not a valid excuse, captain.

To sum up the process with some key highlights:

• Unrealistic requirements - expert advice foreseen

• Poor stakeholder management

• Poor documentation

• No handover when changing project manager

• Massive budget failure

• No room for proper testing - due to pressure on delivery in time

• Toxic leadership

• Ship the entire product at once

It’s not exactly the ground rules of the agile manifesto we are looking at, but even if we for a moment try our best to see the Vasa ship as an incremental change or experiment in a very long product cycle being the Swedish fleet, it’s still everything we try to avoid with experiment-driven development as well. In a digital product comparison, it would be like building the entire product in production right away, making sure to spend the last nickels of your budget to paint the product in actual gold before the release, inviting the entire city to take part in the release ceremony, ignoring the failed stress test right before release, and hoping no one dies.

That’s it. That’s the tale. So:

Whenever someone tries to push for unrealistic requirements without carefully considering expert advice, you tell them about Vasa.

The next time you find yourself arguing with someone who tries to push deadlines down your roadmap, ask them if they have heard the tale of Vasa.

Next time you find yourself explaining agile when marketing is asking for a release date on your next feature so that they can plan for a huge campaign, you tell this story.

So, to make use of this epic failure: Whenever you start up a new project, product, or business, or whenever you see the need, take your stakeholders and partners to the Vasa Museum for a kickoff and tell them the tale of Vasa. Let’s come together, unite, and agree that we never build the Vasa ship again—in any form. Can we all please agree on this now?

And if you still consider the Vasa ship to be built with an agile approach, let’s not build a boat together.

Ahoj,
Gunnar

Always be shipping is a newsletter on product development that is shipped on a not so regular basis - feel free to subscribe.

Subscribe now

Some time ago, during the pandemic, I entertained the idea that Clubhouse would forever disrupt the meeting industry world. I argued that Clubhouse’s social voice app would be the leading platform to enable people to connect and meet, disrupting, for example, Meetup.com. I wrote:

The biggest competitor to Clubhouse are physical meetups and conferences, but that kind of presence is a behavior we need to relearn once we are back to old routines.

I have recently started logging into Meetup again, and I perceive it as a ghost town cluttered with limited features that a Meetup subscription would unlock. But anecdotally (and contradictorily), I was at a Meetup arranged by ProductTank Stockholm this week. The event was my first Meetup since Avanza Tech Meetup cancelled their last planned physical event (about Design systems) in March 2020, when the COVID-19 pandemic broke out in Sweden.

How are people meeting up today? There is a narrative that Generation Z and Millennials are less inclined to use dating apps. I haven’t seen any reports regarding business-related meetups. So, how do we make friends today, both in business and pleasure? I want to discover that further for this newsletter.

Could you imagine that a venture capitalist based in Sweden, EQT, who hosted the Meetup, is product-oriented in some parts? Multiple product managers and owners work there. Product Manager Jonathan Lundmark provided some great insights on the ProductTank meetup, touching on many topics I manage daily as a product owner consultant at the current client.

Some takeaways based on my perception and thought process:

• Having a defined process enables you to analyse incidents deviating from the process.

• Process generates data, and data enables automation (good process reduces garbage in and garbage out).

• Build vs. Buy:

  Building what differentiates and blending with previously bought or built solutions can speed up development of an MVP.

• However, previously bought or built solutions might limit fast changes and company process compliance since vendors lack business context, driving their opinionated product decisions, locking customers in, and increasing lead time for building new and differentiated value based on losing the feature/roadmap control.

• And of course, he touched on my favourite topic - change management:

  People don’t change just because they are shown how, they change when they understand what’s in it for them.”

  Passion cannot be forced, involve people who truly care tarter than relying on org charts for better outcomes.

Mirela Mus from Product People introduced an interesting model on the ProductTank Meetup, the Lippitt-Knoster Model, that covers product teams experiencing ”False starts”, ”Frustration”, ”Resistance”, ”Anxiety”, ”Confusion”, and ultimately ”Change”.

Long time no see. Gunnar and I have been busy since you read the last newsletter. I have switched jobs, started consulting, and founded my venture, which has the same name as the newsletter Always Be Shipping (Gunnar is, of course, an advisor). I’m currently consulting at Scania. What do I do there? Of course, I relentlessly think about how we always can ship value.

I got some taste for writing the newsletter again. One part of it is me trying to figure out the tone of voice for the company and a part of a branding effort for Always Be Shipping. As neatly observed in her newsletter , brands have recently discovered Substack as a potential marketing channel. FeedMe is a great inspiration. Emily crafts the newsletter with a personal tone and a high standard of originality in her reporting of urban professional lifestyles, entrepreneurial personalities and industry trends. You should monitor her reporting to understand the next big thing. It is also a bit nostalgic for me. I have the same cozy feeling when opening a new, fresh issue of FeedMe as when I religiously read the editorial written by Tyler Brule for every issue of Monocle. Sadly, he is not doing that anymore (although he writes every Sunday on Monocle’s daily newsletter).

When I’m deeply interested in something - the learning journey becomes a never ending highway. I read books, I attend events, I debate. I share my thoughts and learnings with people around me and in blog posts. This is something I like to call: Being genuinely interested. It’s when I’m so interested in something that I keep learning more about it without thinking. In fact I can’t help learning more about some topics - it kind of just happened without me knowing. That’s how natural it comes. It’s something that gives me energy and that energy tends to spread across. 

In my early twenties I played in a pop-band and worked part time as a guitar teacher. One of my students  - a kid who had never touched a guitar before - was dropped off by his mom. In our first lesson we talked about what music he liked and why he wanted to learn how to play the guitar. He said that he loved Metallica and would love to play in a rock band one day. I didn’t really know any Metallica songs by heart - so I picked up my iPhone, went to Youtube and found a tutorial on a simple Metallica riff for beginners. We learned the riff together by following the tutorial, and with some additional guidance from me we also covered some theory and techniques as well. 

On our next lesson two weeks later this kid plays two Metallica riffs by heart. And he kept this learning pace for months, he started teaching these songs to his friends and they started a band and performed at the local talent show in town. 

So what’s the point of the story then?  - It sounds like a pretty usual kid-learns-how-to-play-the guitar-and-starts-a-band-story.

The thing is that - I did not teach this kid how to play guitar. I showed him YouTube, and possibly how to learn from it. He being genuinely interested is what made the progress - that’s what made learning so easy and natural to him. That’s what kept him going without anyone telling him what to focus on and what to learn. 

My point is: The same thing goes for work and career. If we work with things we have a genuine interest in, we keep learning, we keep growing, we keep inspiring others without even thinking about it. We glow and we enjoy it. This is not only for our own good - it’s in the interest of the companies we are working for as well. I think of it as the band this kid started, and many other bands that will be started by his friends and friends of friends and the fans of these bands as long as genuinely interested people are doing what they care for. These bands are the culture of a company, the atmosphere, it’s the core of how we collaborate, and how we inspire our surroundings to make things happen. 

Imagine putting together a band of highly educated musicians, putting distorted guitars in their hands, paying them to play Metallica covers - and on top of this expect the band to evolve into something meaningful that inspires others. Good luck with that! Unfortunately this is what we tend to do in the corporate world, with recruitment and team set up, responsibilities and roles. 

It’s possible to make this band play a song now and then, it might even sound quite good. But imagine how much time and energy that needs to be put into making things happen, compared to the Kid who was genuinely interested in doing exactly this. 

If we let go a bit and let the genuinely interested people do the things they care about for real - we would probably not end up with the rock band we had in mind, maybe we end up with a vocal group that sings jazz fusion. But this vocal group is probably much more likely to serve the company’s interest. This is because they will collaborate flawlessly, learn, teach, inspire others without thinking about it. They will be self organised and take the vocal group to the next level, leading the way on how to do so. They will also enjoy life more in general and stay longer with the company. 

My second point is that when we find ourselves playing Metallica covers and being miserable about it, we should be transparent about this. Let everyone know what we really care for and stop trying to convince management we are doing a good job and that we should get paid more to keep the band going. Because the truth is that we are not doing a good job this way. And I can assure you that management would appreciate knowing if you think you could add more value in a different part of the organisation, or by spending more time on a certain project if this makes you glow.

This is the difference between loving your job vs. Thinking you have an ok job: The ones that love their job are genuinely interested in what they are doing. That’s it. There is no one saying that you have to love your job. I’m just saying that allowing yourself and your colleagues to work with the things you are genuinely interested in is what makes the difference. 

And the starting point is you doing something you truly love and care for. How great isn’t that?

Happy to hear your thoughts on this!

/Gunnar Carlén

This is a newsletter published on a not so regular basis - but feel free to subscribe if you found this one of value!

Subscribe now

The first time I showed my work to a client, It wasn't pretty. It was messy and awful in many ways. I opened up for feedback in a way that kind of took apart the entire work I had made. Hurtful things were said, and I lost my credibility in front of a big team. I left that meeting with no idea of how to move my work forward. I made a lot of mistakes that day, and I learned a lot of things too. Even if i didn't realize it until much later.

It’s like music to my ears whenever I receive constructive pointers that put my work in the right direction. Because that’s the entire point of feedback. To move things forward. Unfortunately, that's not always the case. As a designer, I've had my share of badly delivered feedback. And have probably delivered senseless noise to others once or twice over the years. The lesson learned is: I am responsible for the quality of the feedback I receive. And have to set the stage properly to get the feedback I want.

I want to share my way of looking at feedback, and what my mental model looks like when I’m trying my best to do it the right way. I’ve learned a few things to avoid the messy hurtful stuff, and how to make sure that the feedback is meaningful, whether you are giving or receiving feedback. I hope you find it useful!

HOW TO GIVE GREAT FEEDBACK

This is my mental checklist for giving feedback:

1 Did the person in question asked for your feedback? 

If Yes - move on to step 4

If no - move on to step 2

2 Do you have something to say? 

Do you have thoughts or knowledge on the area that you consider to be of value for the person in question?

If yes - move on to step 3

If no - Forever hold your peace

3 Ask for permission to give feedback

This is important and can get messy if done wrong. Try something like:  

“Hey! great work on the X, looks like you are really making progress. I have worked on a similar thing and I have some input that I think you might find valuable moving forward. I would love to share my thoughts on this with you. What do you say?”

This prepares the person i question to listen and take in information. It also opens up for a yes or a no. A yes is great because it sets the stage for what will happen and what to expect in this meeting. A no is not that great but is not very likely if this step is done correctly. 

If yes - move on to step 4

If no - Repeat step 3 later or forever hold your peace 

4 Make sure you understand what the person needs input on

Ask questions like: How can I help you in the right direction? And what do you want me to keep in mind? What do you want me to focus/not focus on? Where are you in this process?

Ask yourself: Do I understand what the person needs input on?

If Yes - move on

If No - repeat step 4

Ask yourself:  Is this something I actually think I’m in position of giving valuable input on.

If Yes - move on

If Else: Explain your level of knowledge on the area and recommend someone else if possible.

5 Deliver feedback in form of a sandwich 🥪

Bread, something in between, bread. Meaning = positive, pointer, positive. 

And it sounds something like: 

I really like how you address the X we talked about earlier. I think spending more time on Y would take this to the next level, and I’m really impressed by your Z skills.

6. Make sure you make sense and that your feedback is helpful. 

Ask questions like: Is my input helpful? Is this of value? Am I addressing the right problems?

If Yes - move on

If else - repeat step 4

Repeat steps 5-6 if needed. 

7. Say thank you.

Finish by saying “Thank you for letting me in on this, I really appreciate it.”  

8. Have no expectations 

Your job here is done. You’ve shared your thoughts in a respectful and meaningful way. Likely this will move the work or the person in question in a direction. But don’t have your hopes too high. What the person decides to do with your feedback is not up to you. Remember that there might be a handful of people with input on this, maybe with very different opinions. 

HOW TO ALWAYS GET GREAT FEEDBACK

With a few adjustments, this model works the other way around and can be used as a mental model for receiving feedback as well. This is how it goes:

1. Ask for feedback. 

Asking for feedback is a way to align, content, and involve the team you're working with. It’s a way to put your work in the right direction and part of the process of getting buy-in on your ideas. Sometimes just showing your work is a way of moving forward – more than the feedback itself. 

It sounds something like this: I know you have a lot of experience on X, I’m working on Y, and would love to have your input on Z. What do you say?

2. Make sure the one giving feedback understands what to focus on and what not to focus on. 

It sounds something like this: 

“This is my process so far. The problem I’m trying to address is.. Changes I made so far.. I would love to hear your expert input on X. At this stage I want you to focus on Y. I need guidance on the direction of Z from an X point of view."

Set the stage as you want it. And make it clear that you are in charge of the work, progress forward, and the decision-making. 

It sounds something like: “I what your input on this before I make my final decisions.”  That way you are in charge of how to use the feedback given. 

Ask if the person is comfortable addressing what you need input on?

Is this something you can help me look into?

3. Make sure the feedback is meaningful and confirm.

It sounds something like this:

Yes, this is what I need input on. This is really helpful. I see - I’ll keep this in mind. You gave me some ideas on how to move on now.

If the feedback isn't helpful repeat step 2. 

4. End sessions by saying thank you. 

You might clarify what was helpful, but feel no obligation. You could just say thanks for your feedback I appreciate our collaboration, and you taking your time looking into this.

5. Choose what to do with the feedback

You are now fully in charge of how to use this feedback. If it’s useful: use it. If it’s not: feel no obligation to clarify why you didn't move forward in a specific direction. 

You’ve now shown your work and opened a focused conversation, pinpointing the right things without giving away the decision-making. You’ve done your best to avoid baseless claims and messy opinions - and you’ve kept your credibility on top all the way!

This is my way of looking at feedback. I hope you find the use of it - And I’m intrigued to hear your thoughts or hacks on the topic. 

Best,
Gunnar

Reading the tech-news outlet last year, they identified Clubhouse as the next rising star. Clubhouse’s latest valuation is around $100 million. The usage and the adoption probably spiked when Elon Musk and Mark Zuckerberg paid a visit.

So far, being an invite-only service, the epicenter seems to be in San Francisco, rapidly spreading to the rest of the world. A couple of weeks ago, I got an invite; the first night on the app felt like tapping into conference calls with entrepreneurs and investors in SF. I also lurked in discussions with Swedish youth politicians that were gossiping and threw around hearty roasts towards each other. The following day, I listened to Swedish entrepreneurs and investors hosting rooms talking about the tech world. Between those calls, I also noticed Swedish influencers gathering their audience having intimate conversations with their fans. At the end of the week, I tapped into a debate where Swedish youth politicians and Swedish parliamentary members debated the future of Clubhouse and Swedish politics.

Is this a severe threat to the big social media companies, such as Facebook, Twitter, Snapchat, Youtube, and TikTok? Thinking as a product person, I believe it will unravel other insights about what value Clubhouse is bringing.

The loneliness has been real the past year. While being socially distant from friends and family, I have Housepartied, Zoomed, swiped, Facetimed, and called them. But those solutions did not induce a new behavior and didn’t make me feel less lonely.

Granted, while my loneliness is triggering me to reach out digitally, I lacked the ability and motivation to mingle. 

Dating apps make me overwhelmed since we’re not yet having a universal solution to socially distant dates away from the keyboard; I believe that video dating is not a viable form of building a connection. I’ve in vain tried to listen to podcasts while doing chores without feeling any sense of reward. My extrovert side could not find a way to substitute meetups and conferences to tune into intelligent panelists. There are still exciting conferences hosted. But those I’ve attended are likely one-way discussions, with a high threshold of motivation to turn on my camera and smile to interact with keynote and debate.

While I get gratification after publishing on Facebook, Twitter, and Instagram, in the form of likes and comments, it is the opposite when I jump into a Clubhouse-discussion; I (hopefully) get an instant reward from a group of people I find interesting. Although there are interactive features on TikTok, Instagram, and Twitch, the barrier to real-time collaboration are high.

Similar to the discontinued service Rdio, human taste and interest compile the Clubhouse-feed. You are not only following followers’ rooms, but you are also observing what your followers are attending. The element of broadcasted talks makes the knowledge ephemeral. You are not able to replay. Thus, users want to invest more time in the app to not miss out on knowledge distributed. 

I argue that Clubhouse is disruptive since it is entering a new niche, accessible sound streaming. You are not only listening, but you can also raise your hand and interact with the podcast, except that it is a room in Clubhouse.

Although Twitter is creating a subset of features called Spaces, the moat is high for similar feature-development; Clubhouse focus on rooms and community is a competitive advantage. Facebook and Twitter are still about people, while Clubhouse is evolving around interests.

The biggest competitor to Clubhouse are physical meetups and conferences, but that kind of presence is a behavior we need to relearn once we are back to old routines.

Speaking of Clubhouse. We have our first book club meetup on Thursday, 6 pm CET. We will hang out and talk about the first pages of Wired for Story by Lisa Cron. Let us know if you want to join us and have a weekly discussion about the book!

Leave a comment

Creativity is a word often used to describe the joy and ambition to create. “My son is creative; he loves to draw.”

Sorry to tell you, mom, but this doesn’t necessarily mean you’re son is creative. The definition of creativity is actually about the ability to solve a problem with the resources you have available.

So. The philosophical question here is, can we be creative without constraints?

MacGyver is an excellent example of what creativity is. He is often stuck in tricky situations, and he always solves his problems using things around him. I have a pen and a paper. I can use it to create a blowgun, shoot a piece of paper and get me out of here.

Compared to: I have a pen and paper. I made a drawing of a car. 

The thing is, we can’t be creative without constraints. Imagine you have endless resources — Elon Musk kind of money, no obligations, and Google-engineers as your team. You are asked to create anything you want. 

- I would build a car.

See — That’s not creativity. 

Compare it to “I made a vehicle out of a chainsaw and a skateboard because I needed to get somewhere, and that was the resources I had available.”

Constraints = the actual essence of creativity. 

We designers are trained in the art of problem-solving. This artform contains methods, processes, and tools to identify, address and solve problems. We focus on one specific problem. We’re not trying to solve just any problem in the world. That’s our first constraint.

The methods we use are the constraints we create. A frame in which we paint, a stage on which we play; a workshop is setting up constraints, to create value. We’re not having a “freeform meeting to come up with ideas”. A design review is setting up constraints around what specific thing to improve. We’re not just having a meeting with opinions on things.

Creatives solve problems within constraints. We’re not just making stuff.

That’s what makes us creative.

That’s what makes us designers.

That’s what also sometimes makes us MacGyver.

Best,
Gunnar

Who wants to join a Clubhouse room on the topic?

Me and Alexander are like many others trying to figure out how to use Clubhouse, and would love to have a chat on how constraints deliver value to the end-users/customers. Join in!

-

Always be shipping is a newsletter on UX / Product Design and Product management by Alexander Forsén and Gunnar Carlén. If you found this letter of value, make sure to get the next one right down in your inbox.

Subscribe now

Like many others, on my first weeks working from home, I was convinced that I would soon go back to the office. My over-optimistic approach stationed me at an ironing board for months before I actually decided to upgrade my workspace at home.

Lesson learned: ironing boards are not a durable, ergonomic workspace, and I have a terrible sense of how long it takes to defeat a global pandemic. I have also learned a couple of other things that I wanted to share with you. So here we go.

👨‍💻 My digital appearance = my appearance

When the meeting rooms moved out of our offices and into our homes, so did our appearance. The only thing we see of each other is a reflection of the faces we remember, now in the form of pixels in video calls. The sad thing is that we don’t even bother making the pixels hi-def for each other. Think about this for a second, the only thing your colleagues have seen of you for the past year is the video-call-persona you now are. You are no longer the small-talking guy in the elevator or the kind coffee machine guy giving tips on how to blend in an espresso in the regular coffee on gray Monday mornings. You have now fully transformed into your digital appearance. At least to the people you work with. Maybe even to your friends.

Another thing that’s really interesting about this, is that the people I got to know during the pandemic has literally no other picture of me than the one produced by my webcam.

So what can we do about this? And is it really that much of a problem?

It took me a while to realize that the only thing my colleges actually saw of me was my silhouette in bad lighting and my voice in poor sound quality. Imagine a physical meeting room with one guy sitting far away in a dark corner trying to tell you something with a low distorted voice. I’m pretty sure that guy will have a hard time gaining trust and getting buy-in on ideas. The same thing applies online. I’m now trying my best to set up good lighting and use proper gear to look and sound as professional as I can at meetings. My recommendation is to invest in gear and lightning to shape up your appearance. Do this, if not for your own sake, but your colleagues. In 2019 you fixed your hair and put on a blazer when you had an important meeting. Working from home, this still makes sense, but I can promise you that crisp video quality and a great sound will help you more than your blazer nowadays.

🔑 1 on 1 meeting = key to connect

The people we used to talk to by the coffee machine or in the elevator, or at lunch are gone. And so are you, in their eyes.

Due to lack of social interaction, working from home, we try to compensate by having social online meetings. Often big gatherings with no agenda, just a space to create interaction and to be social. Over the past year, I've spent a lot of time in social digital meetings. I’m not a huge fan of the format. I’m the guy who sits quietly and listens in without talking much. And I have noticed that I’m not alone, often it’s the same people talking, about the same stuff. No hard feelings; it’s just that I don’t get much out of it.

I find the format poor for connecting, bonding, and getting to know each other on a deeper level. I've had more structured check-in sessions as well, and I think that works much better, not just for me but to actually achieve the goal of creating a social space. This requires some planning and someone to facilitate the meeting, and that might be a problem sometimes. So the thing I want to share with you is something that changes my professional social life radically. I call it: “Give people a call.”

Since I no longer can talk to colleagues and clients by the coffee machine or in the elevator, I’m actually invisible to all the people I don't work close to. And a year without these interactions sure makes a difference. A recently realized that I hadn't talked to some colleagues I really like and used to go for lunch with, for almost a year. So I started calling people up to say hi. This made a huge change. Just a couple of minutes on the phone or in a video call is, in my opinion, a million times better than the scheduled social meetings with no agenda. The thing is, the people we used to talk to by the coffee machine are, in fact, not gone at all. It’s just the coffee machine that is. So give them a call. Stop replacing coffee machines with meetings; people want coffee, not more meetings.

If you read this and haven't heard from me in a while, give me a call! And give the ones you miss having lunch with a call. I’m sure they'll appreciate it.

Another reflection is that the people who I just said hi to every once in a while doesn’t really see me at all – and it might be weird calling those guys up. Being more active on LinkedIn and publishing this newsletter is my way to say: Hey, I’m still saying Hi!

Best,
Gunnar

Always be shipping is a newsletter on Product Design and Product management by Alexander Forsén and Gunnar Carlén. If you found this letter of value make sure to subscribe and get the next one right down into your inbox.

Subscribe now

🌍 What we are doing this week

As we all transformed into pixels on a screen the world around us did too. This made the world a lot smaller. And weirder in many ways. But, a really nice thing about living in a weird world of pixels is that we now have access to a lot more great meetups and conferences worldwide. 

This Thursday, February 4th, me and Alexander are both attending UX & PRODUCT CONF. It’s a conference in the format of debate with a really interesting lineup. 

Maybe we’ll see you there! 

This is a conversation on design and digital stuff; it’s about how we spend our days creating it and our nights trying our best to read books instead of using it. It’s about the products we love and the things we don’t love as much. But more importantly – it’s about sharing the wisdom we gain along the way.

We have been shipping products, features, and design for some time now. And this is our space to brag about our failures and humble brag about our achievements.

Please join us on this bumpy ride of click baits and product stuff – we might learn something – so join the conversation.

ALWAYS BE SHIPPING is best read by:

• Messy designers

• Busy Business thinkers

• Product people in general

• And maybe you

Best,
Gunnar Carlén & Alexander Forsén

Subscribe now

We just realized this is the worst SEO copy ever written, so we’re adding a few tags here so that Google might make sense of this as well. 😂

UX, UI, CX, product design, product development, product owner, and growth hacking