Posted by & filed under Design.

Ever since I launched my little personal project a few weeks ago. I’ve gathered a small posse of real users. And real users, especially those that use the app every day, all have their own specific needs and wants.

Jeff Atwood recently wrote an interesting piece titled: Complaint-Driven Development. He describes how his team used complaints from the user to drive the design of their product. Basically it works like this:

  • Get your software in front of as many real users as you can.
  • Listen to all the things they complain about. It will be… a lot.
  • Identify and fix the top 3 things people keep repeatedly complaining about.
  • Do it again.

I think that this idea works well in theory. I think that the risks lay with the implementation of the idea.

Listen to the need, not the solution

When users formulate complaints, they will often do so in the form of a solution. For example, one of my users told me that they would like to be able to click on the start or end time of an activity and edit them directly with the keyboard.

That complaint is very valid. However, doing it the way it was expressed is a very risky proposition. It increases the complexity of the app and has the potential for making things difficult for my mobile users.

The need behind the complaint was that it was rather difficult to precisely control the position of the slider. It was a little too finicky. So, I formed a hypothesis that if I made the scale for the sliders more relevant to a normal workday, it would be less tricky to get it to stop on the right time. I released that and hopefully, users will be able to prove or disprove that hypothesis.

Always check against your product vision

User complaints can pull you in all kinds of directions. A guide that I am using to filter that out is to check against my original product vision. In particular, I wanted to make sure that I don’t stray away from some of the company objectives like increasing the quality of the timesheet notes. Sometimes those don’t perfectly align with solving your user’s complaints.

And like everything else, I need to recognize that the original product vision is itself a hypothesis and it needs to be put back on the table if needed.

Be grateful for user complaints

The most exciting about this little project of mine is that I have actual real users. When I started it, I knew that I would use but that was it. I built a huge backlog of things that I wanted to add. 16 years of software experience told me to do that. My real users are making me realize that this long infinite todo list is filled with things that are not that important nor are they valuable.

With real users, that long infinite todo list seems a lot smaller.


Posted by & filed under Design, Work.

TL;DR: I made a tool to help with timesheets. Let me know what you think.

For as long as I’ve been in the service industry, one of the most universally detested tools that me and my colleagues have been using has been the tool used to capture worked time. Getting employees to fill their timesheet accurately and in a timely manner has been a constant struggle for my company. Sometimes, we use the carrot, sometimes we use the stick, but nothing ever seems to work.

It doesn’t help that the timesheet tools that we’ve been using have always had pretty bad user experiences. They are usually large, slow, and they force the user into a workflow that seems completely unnatural. The tool of choice right now for our company is SAP Business ByDesign which is a particularly horrible example for timesheet software. A lot of people at the office are keeping a document on the side to take notes about their work. Only going into ByD once a week to transcribe their notes, hoping that it won’t crash and that they’ll only have to do it once.

Why don’t you use toggl (or Klok, etc…)

Each time I mention timesheets at work, someone unavoidably asks me “Why don’t you use that other tool there?”.

There are a large number of alternative solutions for time tracking. A lot of these solutions are even free. So, why wouldn’t we use one of those if ByD is so horrible. From a company standpoint, the answer is simple. It’s already been 2 years since the integration of ByD in all the corporate systems has started and it is still ongoing. That train has left the station and it is not coming back.

So we are back to individual decisions to use something else out there to take notes and going in once in a while to transcribe our notes in ByD.

You’re a designer, why don’t you design a better timesheet?

OK, that’s something else I heard a lot when I was complaining about the timesheet. 3 years ago, I decided to spend a few days on that problem. I did user interview, and collected feedback, examined the workaround that other employees used to deal with their timesheet.

Here’s the bullet-form result of that research:

What the user needs:

  • It needs to be fast
  • It needs to allow quick note-taking as I work
  • It needs to do the math for me
  • It needs to keep me informed about how my day/week is going in terms of worked hours
  • It needs to acknowledge the fact that I often do the same thing day after day

What the company needs:

  • Worked time needs to be submitted on time (the invoicing workflow starts with the data in the timesheet)
  • Worked time needs to be separated by project (for invoices)
  • Worked time needs to have descriptive notes attached (for invoice justification and tax credits)

I presented my findings and a preliminary design to the company. Hoping that someone with the right programming skills would pick-up the design and push the project further.

That didn’t work so well so I decided to take matters into my own hands.I googled to figure-out what the new hotness was for web development and I got to work.

So I didn’t design a timesheet

timeLog Screenshot

So, it seems that the solution didn’t reside in building a better timesheet. Other people have already solved that problem. I’m thinking that instead, I was going to build a time-aware log book.

So, here are my design intents:

  • Focus on note-taking instead of time-tracking
  • Optimize speed of note-taking
  • No math required
  • Acknowledge that tracked items repeat from day-to-day/ week-to-week
  • Make it easy to feed data back into ByD

So, after spending 2 weekends working on the app and dogfooding it for one week, I’m ready to unleash it on the world.

You can try it at:

All you need is a Google login and you’re good to go.

It is still a little rough around the edges. However, I’m pretty happy with the results. It works well on mobile browsers and on the desktop. Used it to fill my timesheet this week and I did it without a backup note-taking method.

What is next for the Time Log?

Hopefully, a few people at the office will choose to try the application and give me some good feedback to improve it. I certainly plan to keep on using the application every day and improve it as I keep stumbling on its limitations.

I don’t want to stuff that thing full of features but there’s a couple of things that I would like to eventually get done if I get the chance:

  • I would love to find an API that I can use to automatically push the data from the time log into ByD. I’m still looking but I can’t find anything.
  • I want the app to remember notes that I have already typed in the recent past for a given projet and help me with the typing as I fill my notes.
  • I think I’ll try to integrate with my google calendar and allow to automatically slide-in my meetings into the time log.

If you try it or if you have any thoughts, I’d like to hear from you.

Posted by & filed under Uncategorized.

All of last year, I spent working on an EHR redesign project. Unfortunately, the project ended before I had an opportunity to tackle all of the things we wanted to do. One of the things that I wanted to get a stab at and wasn’t able to was immunization support. Immunizations are relatively complex to handle in an EHR. Especially if you want to do a little more than just record the immunizations given. If you want to support the doctor’s decision process, you have to put some effort into it.

Each year, the CDC publishes guidelines for immunizations. These guidelines propose an immunization schedule, it describes when to administer the various kinds of vaccines, and it also offers options for catch-up vaccinations and how to deal with various exceptions and edge cases.

As you can probably guess, these guidelines are rather complex and they basically read like a computer algorithm.

Here’s an example for Hepatitis B

Hepatitis B (HepB) vaccine. (Minimum age: birth)

Routine vaccination:
At birth

  • Administer monovalent HepB vaccine to all newborns before hospital discharge.
  • For infants born to hepatitis B surface antigen (HBsAg)–positive mothers, administer HepB vaccine and 0.5 mL of hepatitis B immune globulin (HBIG) within 12 hours of birth. These infants should be tested for HBsAg and antibody to HBsAg (anti-HBs) 1 to 2 months after completion of the HepB series, at age 9 through 18 months (preferably at the next well-child visit).
  • If mother’s HBsAg status is unknown, within 12 hours of birth administer HepB vaccine to all infants regardless of birth weight. For infants weighing <2,000 grams, administer HBIG in addition to HepB within 12 hours of birth. Determine mother’s HBsAg status as soon as possible and, if she is HBsAg-positive, also administer HBIG for infants weighing ≥2,000 grams (no later than age 1 week).

Doses following the birth dose

  • The second dose should be administered at age 1 or 2 months. Monovalent HepB vaccine should be used for doses administered before age 6 weeks.
  • Infants who did not receive a birth dose should receive 3 doses of a HepB-containing vaccine on a schedule of 0, 1 to 2 months, and 6 months starting as soon as feasible. See Figure 2.
  • The minimum interval between dose 1 and dose 2 is 4 weeks and between dose 2 and 3 is 8 weeks. The final (third or fourth) dose in the HepB vaccine series should be administered no earlier than age 24 weeks, and at least 16 weeks after the first dose.
  • Administration of a total of 4 doses of HepB vaccine is recommended when a combination vaccine containing HepB is administered after the birth dose.

Catch-up vaccination:

  • Unvaccinated persons should complete a 3-dose series.
  • A 2-dose series (doses separated by at least 4 months) of adult formulation Recombivax HB is licensed for use in children aged 11 through 15 years.
  • For other catch-up issues, see Figure 2.

Over the years, the CDC has learned to organize this information in a way that doctors can understand well. They publish this information in two PDF documents that break down these guidelines in a nice vaccination schedule which looks like this:
0-18yrs-schedule example

They also publish a web version that is meant to be embedded into hospitals web sites and other content. This re-interpretation to the web degrades the quality of the information offered a little bit (breaks the schedule down, clumsier table layout) but it is still pretty good.

Now, bring that inside the EHR

Immunization support in EHRs vary greatly from vendor to vendor. On the one end, some systems simply record received immunization as line-items in a table. Others implement complex rules-based systems that attempt to reproduce the various CDC recommendations (including exceptions and catch-up schedules) to give the practitioner precise due dates for the patient’s immunization.

In theory, bringing this information inside an EHR situation should help simplify things, not make it more complicated. After all, you know more details about the patient (gender, age, past immunization history) and you know more about the practice (which vaccines the clinic has in stock or typically gives), and you actually know which specific vaccine was administered to the patient in the past. Given this fact, the EHR should be able to properly map-out the patient’s immunization schedule and tell the doctor exactly when the vaccines need to be administered.

In practice, I feel that trying to out-think the doctor and pick-out very precise due-dates for immunizations if the wrong way to go about this problem. Here’s why I think that:


If the EHR has the required code to properly represent and codify all those CDC rules (that is a big if), it potentially can represent proper target dates for the patient’s immunization. But that is only half the equation. The doctor has to trust that the guidelines represented in the software are accurate, that they are implemented correctly, and that they can trust the result to make clinical decision.

The issue with trust is that it is fragile. You’re not allowed to make a mistake. The minute you do, you will erode the doctor’s trust in your EHR’s ability to help with the clinical decision. To complicate matters more, you are helping a highly trained expert user make clinical decisions. This is their field of expertise. You are however putting your software in a potential position of conflict. It is very possible that you have more up-to-date information than them. For example, the CDC guidelines might have been updated or the software might have detected an edge case that the doctor is not aware of. Technically, this is a good thing, you always want to have the most accurate information. But to your expert, you have to earn the right to challenge their expertise.


So you’re damned if you’re right, and damned if you’re wrong. How do you mitigate this? As with all the complex processes, one of the best ways to help your user trust the process is to show them how the sausage is made. This sounds counter-intuitive but, if your immunization system triggers a special rule, make sure that this is clear to the user. Better yet, show the user the state that triggers the “standard” rule to fail and give them the control over which special case gets applied.

Most users, especially expert users, want to be in control. Giving your user the best information about the patient’s immunization and asking them to make the final call about the course of vaccination to give will support their decision making process without taking control away from them. This will help them be more accepting with situations when you have more accurate (or up-to-date) information than they do about guidelines. It will also help when they know something about the patient that the system doesn’t know or doesn’t have the necessary code to handle.


The CDC has been publishing those guidelines for a long time and the doctor is likely to be familiar with the method that the CDC is using to represent the guidelines. Here are some characteristics of the CDC guidelines information design:

  • Schedule is represented as a timeline based on the patient’s age.
  • Target dates for the doses are represented as time windows not specific due dates
  • The colour scheme for target dose windows, catch-up schedules and special cases is well established
  • Vaccines are grouped by disease, then by course of treatment
  • Language/terminology is very specific

I’m not saying that it is impossible to improve on the CDC’s information design but, since it is the source that is used by most of the doctors, the basic structure of the design should only be changed with great care if at all. Your new design might be better but it will not feel so familiar to your user.

That being said, in an EHR setting, you have more information to show the user than basic guidelines from the CDC:

  • You have a history of past vaccinations
  • You know the age of the patient
  • You know which specific series the patient is on at the moment
  • You know if the patient is on the regular or the catch-up schedule

The design work at this point is to find an efficient way to represent this extra information by adding to the CDC’s design language without breaking it or conflicting with it. Keeping the CDC guidelines visually and conceptually consistent will help the user distinguish between what is the guideline and what is the patient’s data.


Guidelines are just that. Once you put them in practice, doctors will make judgement calls every day that might not directly comply with the guidelines. A trustworthy system would accept these variations well and find a way to represent them within the right context. A system that is overly smart and starts going crazy the minute you step outside the lines will erode the doctor’s trust.

If the doctor decides to draw outside the lines, let them do it, it is ok to flag the various entries as being non-compliant with the guidelines but don’t make the doctor feel like they are making a mistake. Resist the urge to trigger a symphony of alarms. Find a way to represent those non-compliant entries within the framework of the guidelines. If you can, try to add helpful information about how the guidelines propose to solve those edge cases. For example, you can attempt to represent the catchup schedule’s data on the main guidelines. Or at the very least, find a way to point the user to the right, up-to-date documentation regarding this exception.

Build on the shoulders of giants

Immunizations is a situation where there are clear best-practices published by an authority on the subject. Make sure that your design efforts don’t go against the authority and expertise of that authority. Find places where you can help the doctor make a decision by adding details to this baseline information.

I didn’t get to solve that problem in the context of my project. But I did spend a lot of time thinking about it since the project has ended. If I have a bit more time, I might actually take a stab at a concept of two for bringing this solution to life.

Posted by & filed under Design, Work.

Here’s a recording of a webinar I gave to the Avaya DevConnect community on May 1st. The webinar was intended for a product manager/developer audience.

It goes through some tips, mostly about how to work better with your designers and get a little better about design yourself.

Most of the content is from various sources that have helped me learn my job over the years (they are listed in the back of the presentation). The section about Understanding your user is based on the Boxes and Arrows article called: Are your users S.T.U.P.I.D?

Hopefully, you will find this presentation useful or entertaining. It lasts about 45 minutes.

Posted by & filed under Design, Security.

Today, I witnessed someone struggle to login to a system they weren’t using very often. After a couple of missed password attempts, they went straight to the forgot my password functionality. It made me think of an interesting alternative for login.

Imagine this: for web sites or services that support a feature to reset passwords by email. In addition to the link to reset the password, why not add a link that says: log me in by email.

That option, instead of resetting your password, it would just send you a link with a unique, randomized, time-boxed, one-time key. clicking the link would just log you in as if you had typed your password. This would be much faster than forcing the user to reset the password. And really, since the service already supports resetting via email, and wouldn’t really be less secure than sending a link to reset the password.

This is clearly not an option for services you use very often. It is slower than actually remembering your password. However, for services you don’t use very often, I actually think that this is a better option. It would also be a good option for mobile usage where you might not have access to a password manager. That would grant the user access without forcing the user to reset the password.

Once you implement a feature like this in your system, it might also be extended to allow granting access for single purposes. For example, WordPress sends you an email when comments need moderation on your blog. Clicking the link forces you to login to your Wordpress blog to complete the process. If the link had a single-use authentication token attached. It would let you approve or reject the comment without forcing your to login.


Posted by & filed under Design.

Let’s play a game: I took screenshots of some apps on my phone and I removed pretty much all the content and other identifying marks. Can you still identify the apps?

App A


App B


App C


App D


Did you guess? Here’s the answer in case you didn’t:

  1. Evernote
  2. Facebook
  3. Twitter
  4. Yelp

All those screenshots were taken on iOS. In this familiar, consistent environment, the 4 applications are easily recognizable as their own individual brands.

What happens to that brand identity when you start moving the applications to different platforms? What do you preserve?

Let’s see:


Blackberry Twitter app

Web version

Blackberry web applicatoin

Windows Phone 8

Twitter Windows Phone 8


Twitter Android 

From those screengrabs, we can see that the Twitter look and feel is very consistent between the web version, the iOS version and the Blackberry 10 version. When we move to the Android and Windows Phone 8, the choice was made to move closer to the platform look and feel and a little further away from the twitter look and feel.

When you choose to do that, You have to use a more subtle way to express your branding. You have to be consistent with your color schemes, typography, icons and hopefully, you can squeeze your logo in there. But is that enough?

Looking at the Android and Windows Phone 8 applications, would they still be as recognizable if I went into photoshop and did the same thing to them that I did to the iOS app?

Why did they choose to stick to their iOS branding for BB10 but not for WP8 and Android? Is it because the platform is so new? Is it because Android users get upset when you give them an app that looks like an iOS app?


Posted by & filed under Technology, Work.

Since Macadamian (my employer) is heavily involved in the creation of applications for the new BlackBerry 10 device, I was handed a brand new Z10 to use as my phone and get familiar with the device, OS and apps.

As the owner of an iPhone 4S, it was a great opportunity to compare the two. Plus, it is the same sim card format so I always had the safety blanket of switching back if I ever got stuck.

After a week of using the Z10 as my primary phone, here are some of my impressions.

The device

The Z10 feels well built and solid. The screen is large, very crisp, and brightly lit. Even though the Z10 is lighter than my iPhone, it doesn’t feel plasticky or toyish. At first glance (completely subjective), I would also say that the battery life is similar to my iPhone.
The Z10 is fast (again, completely subjective opinion) and it feels very snappy and fluid when using the apps.

The OS

Switching phones is a rather frustrating exercise as many of the interactions that I have been using for years now on the iPhone need to be re-learned. Simple things become complex again like switching apps, opening menus, selecting text or answering emails.
That being said, once you learn some of the basics of navigating around the BB10 OS, it becomes familiar quite fast. I am a little ashamed to admit that it took me way longer than expected to figure-out how to select text when typing.
As a user switching from iOS, BB10 was not as unfamiliar as say Windows Phone 8. But it is a departure. I would say that BB10’s visual language and interaction principles stand somewhere between Android and Windows Phone 8.
It is a little like Android in the way it presents its launch icons, default toolbars, and hierarchical navigation principles for apps. And it is also a little like WP8 in the way that it tries really hard to remove excessive chrome to make you interact directly with the content. It also has these active tiles to represent running apps that have a hint of the WP8 thing going (but maybe it is just me)
One thing that wants to be BB10’s claim to fame is the BlackBerry Hub. This is BB10’s central location for everything that is messaging related. So far, it feels like a giant inbox that gives you centralized access to everything that gets pushed to you. Don’t look for a mail app in BB10. All of this happens through the hub.

But, would I switch?

For me, at this point, it’s all about the software.There is a handful of apps that I use all the time that are not available yet. Feedly, 1Password, and Yelp are being missed dearly and made me pull-out the iPhone during the week.Another must-fix at this point is the fact there was not a way to accept calendar invites coming from Google calendar directly in the BB hub. That is not really acceptable and has to be fixed.

The Blackberry Link desktop software is clumsy on the Mac. It uses an installer (instead of just copying to the Applications folder) and it forces you to reboot on install. Additionally, it won’t sync photos to/from the Aperture library, only from iPhoto. I haven’t yet figured-out how to get photos out of the device and I have resorted to emailing them to myself.

So would I switch?

Not yet… but maybe soon. There are a lot of big-names working on their BB apps right now and OS updates are sure to come to fix some of the remaining rough edges. I certainly will keep using it as my main phone for a little while and see the updates come in.  But always with my iPhone as a safety blanket.


Posted by & filed under Design, Work.

I’ve had my eye on this conference for 2 years now and couldn’t find a justification to go. This year, it was in Toronto, a short hop from home so I had no reason not to go. Now that I am back home, here are a few thoughts on Interaction 13.

This conference was 4 days x 3 tracks of wall-to-wall talks. A week-long marathon of learning, networking and discussions. It was a complete immersion in the international community of interaction designers.

I won’t to go through an in-detail description of every talk I attended. But here are some of the highlights; Talks that stood-out for me.

Tense-up: Creating positive tensions in experiences

by Matt Walsh

Tension is a tool that can be leveraged by the designer to help with engagement. Rather, the relief that you provide by releasing tension can be used effectively. Obviously, you can create tension (like creating scarcity) but you can also endeavour to find existing tension in the system (like social tension) and offer a relief for it. The talk gave great insights on how to spot tension and copious real-world examples.

Quote: “Tension creates potential energy”

Compliance: Design to facilitate a healthcare service

by Audrey Richard-Laurent

This beautiful and inspiring short talk went through an overview of a design exercise to help a specific kind of population navigate the healthcare system of a polyclinique in France (don’t remember the city). I loved the very pragmatic, empathetic approach taken and especially the fact that it didn’t end-up being a technology-centered solution.

Quote: “Care first, Admin Second”

Rhythm, flow and style

by Peter Stahl

I liked this presentation. It was a practical, down-to-earth presentation about specific things to use rhythm (both in the user and in the software) to encourage your user and potentially even induce a state of flow. He went through the characteristics of flow and what induces it. (known goals, balance between skill/challenge, sense of control, etc…)

Basically, when we design interactions, we are choreographing people’s attention. That requires a certain amount of rhythm and tempo. The classic tools of the trade (like wireframe) often fail at communicating that and we have to start thinking about maybe augmenting the toolbox here.

Quote: “You dig channels and hope that people’s attention flows in it”


How to design social experiences

by Paul Adams

This was a great presentation. Well structured, well delivered. I didn’t take that many notes because I was completely into the subject. Paul Adams went through a lot of what they learned at Facebook working the social relationships.  From the characteristics of human needs to how we organize our friends in real life.

Basically, we build relationships with many lightweight interactions over time. Companies build destinations where they expect users to go “experience the brand” when in reality, they want to have small interactions and build the relationship over time.

Quote: “Stop building destinations. Design the story first, they reverse engineer the system to support the story”

If UX can kill it probably will

by Trip ODell

Trip ODell went through the process that they used to redesign the application to make it safer for users that used it in the car. Even through not using the app in the car is still the safest way to go, they acknowledged that there was no way to stop their users from using it in the car. Might as well make it safer. He felt an ethical responsibility to do that.

He went through basics about how the brain processes stimulus and the various parts of the brain that handle the various stimulus. Because the various stimulus sometimes take different paths to the brain, sometimes, it creates a conflict and the stimulus has to be handled by higher functions of the brain instead of the more automatic responses.

The limited capacity of the brain is the reason, why after an accident, the motorist would often say: “I didn’t see the pedestrian”. When in reality, if the brain was overloaded, the motorist saw the pedestrian, he just didn’t remember seeing it.

Quote: “Design for the hunter gatherer brain”


On aircraft and craft

by Dane Petersen

This was a delightful presentation centered around the design of famed aircraft designer Burt Rutan. It was a short presentation and the only thing I could do during that presentation was to lean-in and just take it in. He basically went through the Rutan’s portfolio and extracted the essence of it and showed the thread that linked all the designs together.

This talk made me seriously consider my resume.

Quote: “You are a mashup of your design experience. The focus of your expertise is your craft. You construct the narrative of your craft.”


Designing a compassionate healthcare experience

by James Senior

I was touched by James Senior’s talk about how they use compassion in their design process at the Mayo clinic. Through examples, he showed how the designers at Mayo use their compassion in the design of the Mayo patient experience.

I particularly liked the concept of the distress interaction. The distress interaction as the characteristic of:  being undesired, being under pressure, and allowing the user to envision relief. Interesting way to reframe the problem.

Quote: “Compassion is empathy in action”

Posted by & filed under Uncategorized.

Axe in Wood by brittgow

I like the (American) Thanksgiving break. Especially the fact that, being Canadian and all, I work during the Thanksgiving break.

However, since my customer right now is American, everyone I deal with is eating turkey and watching football.


Posted by & filed under Uncategorized.

A goal is a dream with a deadline
     — Napoleon Hill (wikiquote)

This quote has almost become a cliche and many people have reused it in one way or another. You mostly see it in the form that Dr. Phil uses: A goal without a deadline is just a dream.

This week marks the 1 year anniversary where my long standing dream of being healthier became a goal. About a year ago, I stood in front of a bunch of my colleagues in a Toastmasters meeting and I stated, out loud, that I would loose 50 lbs before July 1st.

Goals are tricky, once you commit to a deadline and turn your dreams into goals, you expose yourself to missing the mark. And miss the mark you will. When I reached July and had met my goal. I re-set my goalpost. I wanted to reach 200 lbs by Valentine’s day. And it is clear now that I won’t meet that goal. I made good progress but I missed my mark.

It turns-out that missing your mark ain’t so bad. I think that once you start missing your objectives, you become more comfortable setting them and you get more out of your goals. You learn a lot aout yourself and about the goal you’re trying to achieve. Achieving a goal is great and missing the goal kinda sucks. But it is much better than not setting one.

That being said, no one wants to miss goal after goal. So, another good thing about setting goals is that it keeps you honest and realistic. Setting a goal is a commitment to yourself and being honest about it forces you to gauge your ability to achieve it before you start. You can set stretch goals but you can only stretch so much.

So it is time to move my goalpost again. To reach a healthy weight for my height and age, I have to be just under the 190 lbs mark. So, my new goal is to reach that weight by July 1st.

P.S. Sorry for the personal, self-congratulatory, somewhat off-topic post. Let me bring it back on topic a little. This also applies to products, teams, and workplaces. Grand visions without deadlines are just wishful thinking. But we all knew that right?