The Power of Habit – Book Tip

cover_power-of-habit

When the insanely insightful Amy Hoy is smitten with a book, I read it. And “The Power of Habit” did not disappoint!

It’s an entertaining journey through cases that helped scientists uncover how habits (and willpower) work and how you can change them. Understanding why and how our automatic actions play out is highly important, given that they govern about 40% of all our daily actions – A staggeringly high amount.

I highly recommend reading the book! As an appetizer, here’s an excerpt on how to change a habit by changing the routine within the Cue-Routine-Reward loop.

Let’s close with some quotes I highlighted during reading: Continue reading

Retr-O-Mat Print Edition – Prototypes

Do you like product development documentations such as “Made by Hand“? I love them! I love to see how something takes form.

That’s why I’d like to share with you how the Retr-O-Mat Print Edition came into being:

Format

First things first: I needed to settle on a format that allowed for viewing 5 different “slots” at the same time and for easy switching between activities. I thought of printing the activities on business cards and putting them in a box with 5 compartments. Given that I had no idea how many units I could sell the upfront costs of 50 different kinds of business cards + custom boxes were too high.

Then I thought of these children’s books with flaps which let you combine heads, bodies and legs into fantastic animals. Naturally it would have to be a longish format with a stable back because it would have to be stable even with most of its pages cut into flaps. I could not find a suitable brochure printer but I did find a – pause for effect – table calendar:

table-calendarThe back of each and every Print Retr-O-Mat out there consists of two paperboards glued together and the overlapping bit cut off.

[Fun(?) fact: The final print job was delayed because there IS the option to print this format as a brochure after all - not that you can find on the printer's website, mind you. The printer was wondering if I mis-ordered and paused my order. It would have saved a lot of work, but I did not want to order 220 copies with a back I'd never seen before. So I went with the option I had prototyped. But I'll check out a prototype with the brochure back before ordering the potential 2nd round.]

Color Scheme

I wanted the print version to reflect the digital one, so I spend a lot of time on getting the colors right:

  • It shouldn’t be too many different colors
  • Neighboring flaps must have visibly different colors – not only on screen, but printed
  • One page = one plan = one base color, so that you have some notion of which activities work well together IMO

color-schemeOver the course of 4 weeks and several prototypes I went through at least 5 different color combinations, until I was happy with one.

Elastic Cord

cordTo be usable, there needed to be some way to fix the flaps in place. As there are not that many different cords and colors to pick from, it was easy to choose. Only the light blue cord looked nice with the other colors.

Proof of Concept

pre-alphaThis is an early proof of concept to see how it would feel to flip through the phases. It already contains activities to get a feeling for length. At this point I had already shortened the activities to fit on the flaps. Continue reading

Retr-O-Mat Print Edition – Stats

Now that the Retr-O-Mat Print Edition has sold out, I’ve had time to crunch some numbers. For all the people out there who like charts and data porn (or plan a similar project), here’s a breakdown of Print Retr-O-Mat’s numbers:

  • Copies ordered from printer: 220
  • Copies meeting my quality standards: ~160
  • Sold: 145
  • Send out as “Thank you” copies: 15
  • Donated: 10 (these had minor flaws)

Countries shipped to

My first sale ever shipped to the USA. I shipped to 16 countries in total \o/

The Top 4:

country-breakdown

Other = Canada, Czech Republic, Netherlands, Switzerland, Belgium, Chile, China, France, New Zealand, Norway, Poland, Portugal

 

 

Lost packages

3 packages didn’t reach their recipient the first time, so I had to resend them: Continue reading

Don’t bundle tasks – A tale of two stickers

Back in While we’re at it…, I recommended not to bundle tasks, however tempting it might be. In the meantime I gave into temptation and promptly got a cautionary tale about bundling tasks of very different priorities:

I was working on the Retr-O-Mat Print Edition and decided to throw in some stickers (bottom sticker in photo below). While I was at it I decided I might as well create some stickers for my new project Wall-Skills.com as well. (That was not yet the mistake.)

stickers

My critical error was to bundle up both stickers in one order, although the Retr-O-Mat sticker was really important to me and the Wall-Skills sticker was a nice-to-have. What can I say, there was plenty of time and wanted to save shipping cost. It seemed like a good idea at the time…
I ordered the stickers and went on vacation.

Upon my return, the finished stickers had not yet arrived. Neither had the finished Retr-O-Mat copies. Both was unexpected and unwelcome, since I had pre-orders and rush pre-orders :(
I didn’t want to let anyone down.

Out of the two missing shipments, the actual Retr-O-Mat copies were more important so I followed up on them first. When they finally arrived, my head was free to phone up the sticker company. Apparently they had printed both kinds of stickers, but then misplaced the Wall-Skills.com ones. So the Retr-O-Mat ones I really cared about, had been sitting around for weeks. No value without delivery to the customer… In the end they shipped the Retr-O-Mat stickers first and reprinted the others.

But the first batch of copies went out without the nice stickers :(
This is the much more attractive second batch:

stickers-on-envelope

So this was an instance in which I really wished I had taken my own advice…
In my experience this is how it happens in software, too. Bundling makes sense, it saves on $foobar and you’ve got time to spare. Until you haven’t.

PS: Another lesson is not to order print jobs right before Christmas. But I just couldn’t curb my enthusiam.

Evolution of team setups

Ever since my employer adopted agile some 4 years, ago, we’ve developed our products with a variety of team “configurations”. Here’s a short overview of what we’ve tried and why product teams take the crown so far.

Pre-Scrum: Silos

In pre-Scrum times there were no real teams, but rather groups of people with a similar skill set who shared a room. Everyone had their own tasks to work on. We had a room full of web developers, one with perl hoshis, another one where the project managers sat, and so forth.

 silo

The seperation was unfortunate. A nice example dates back to 2010: There is a page that lists all groups in a customer’s sipgate team account. This page had agonizingly long loading times. I’m talking minutes here. Upon closer inspection it turned out that the page requested lots of information from the backend, although it only needed to show little pieces of the requested data. There wasn’t a backend function that delivered precisely what the web page needed. And as web developers and backend developers were working separately the web developers collected the data they needed from methods that were already available, rather than wait for a method to be custom made.

Scrum: Cross-functional Teams

Today it would go differently, because in 2010 we adopted Scrum: We build real, cross-functional teams, consisting of web devs, backend devs, a designer or UX person and a product owner (a re-purposed project manager). One of the devs doubled as scrum master in each team. Such a team worked on shared tasks and could build a complete piece of new functionality.

 scrum-team

With this setup we were already developing much faster than before. Pre-Scrum feature development had often dragged along. Now the 5 product owners were hard pressed to come up with enough work for all teams. So far, so good.

Continue reading

The Product Owner’s tasks according to the Dev Team

One of the questions that inspired Mail-Skills.com is: “What do you expect of a PO? What are her tasks?”

As always, the answer is “It depends”. One major influence on what I expect from a PO is maturity. Not the PO’s, the Dev Team’s.

A team that’s recently started using Scrum usually expects a user story to come with a subset of the following:

  1.  detailed description
    • sometimes with a specific solution
  2. further details as acceptance criteria
  3. list of test cases
  4. Photoshop mockups of all interfaces
  5. everything clarified with stakeholders

Can you feel the remnants of a compartmentalized, planning-heavy process?
Yet, I wouldn’t try to shake all of the habits right away. A PO trying to share those duties with the team rightaway will often be seen as not doing her job. “That’s what YOU’re here for, aren’t you? Do we have to do your job, too?”
Heaven forbid that the dev team have to clarify details with a marketing guy themselves…

The trick is for everyone to slowly evolve from “everything’s pre-chewed” to “we can and want to do this together – results will be better”.

A PO that fulfills none of the above can actually be a great PO – to a mature team. Much better than one who stifles the team’s creativity by over-specifying everything: Continue reading