Productivity Hack The Chime Method

Productivity Hack: The Chime Method

We all love to procrastinate, to find anything to distract us from doing that thing that we have to do, there is a pleasure in it, otherwise it would not be a problem. Jessica Hische said: “The work you do while you procrastinate is probably the work you should be doing for the rest of your life.”.
The problem is, I don’t know if browsing Twitter, 9gag, and reading tech news is something that I can do for living.

As a person who does not like to be involved in methods that are invasive, and that require your active attention like the pomodoro technique, I looked for methods that are less invasive, that can work without having to devote any attention or a specific action for that method to work.
I’ve found that methods like the 2 minute rule and similar ones which require a small change in habits are easily forgotten and hard to stick by.

The Chime Method

The idea was inspired by the chime of watches and clocks, I figured out that it is a perfect way to use it to manage time effectively.
I downloaded an app called Caynax Hourly Chime where I defined a 30 minute rule chime. The chime served as a productivity checkpoint to check if I was productive enough in the past 30 minutes, which was also an excellent way to alert me if by any chance I started to procrastinate, forcing me to go back to what I was originally doing.

I’ve found that this method is simple, non-invasive and requires no action once it is set up, there is no need to interact with your phone or dismiss any notification, it just works in the background.

The chime method is an excellent way to manage your time effectively and keep a track on time, hearing the chime in any place or any situation is a good way to evaluate if what you’re doing now is taking longer than it should and if you need to let go of what you’re doing and move forward.

The GIF way of reporting bugs

No system is free of bugs. Reporting bugs in an effective way starts all the way from writing a clear summary, a steps to reproduce (STR), expected results, actual results and then providing other detailed information about the bug, you can read about it in details in Principles of Good Bug Reporting, however, in this post you’ll learn the GIF way of reporting bugs.

If your product is mostly a consumer facing product and most of the interaction is on the user interface, then most probably a lot of bugs are visual, having a clear summary, STR and detailed information is sometimes not that effective, developers may fail to see the problem, attaching a screenshot helps most of the time, but sometimes when the bug is related to the interaction with certain elements, the only way to see it is to point it out live to someone.

A bullet proof method of reporting bugs that I have found is using GIFs, I know you might be reading  this right now thinking “Oh my! not GIFs again, it is getting out of hand” but this is a method that I introduced at Mapme where I use it myself to report bugs as well as our QA Engineers.

the-gif-way-of-reporting-bugs

So how do you report bugs the GIF way?

 

1. Get a GIF screen recording software

  • If you’re using Mac OS,  GifGrabber is a simple and a free tool to record GIFs, it can be downloaded from itunes. There might be other tools like recordit which was mentioned recently in Product Hunt, but I found GifGrabber to satisfy my needs.
  • If you’re using Windows, try using Screen to GIF.
  • If you’re using Linux, you’ll probably know how to use google and won’t need my recommendation.

2. Find a UI bug

Visual bugs are best suited for GIFs or anything that is directly related to the UI, the best way to use the most of the GIF way of reporting bugs is to have something that changes on user’s interaction like clicking, hovering, or scrolling.

3. Reproduce the bug

Before recording the bug, try to reproduce it, see how you can get the best shot, see if it will always reproduce and if everything is clear.

4. Start recording

Resize the reorder window to the area where the bug is present, make sure that you’re going to capture the whole area where the problem is happening, start recording and reproduce the bug while recording.

GIF Capture

 

5. Trim and save

A lot of GIF recording software give you the option to trim the GIF from the start and the finish of the recording, so if anything was recorded that is unrelated to reproducing the bug it should be trimmed out to avoid any confusion.
When saving a GIF file, make sure that it is not going to produce a huge file (5MB or more), in order to reduce the file size try to adjust the settings like frame rate and the dimensions (zoom size) without sacrificing the quality, large GIF files take a lot of time to load and sometimes fail to play.

 

GIF recording of a bug

 

6. Report the bug

Having a GIF is enough to save you on writing the Steps to Reproduce (STR) and the detailed information, but that does not mean that it is not necessary, if you’re a fast paced startup, then having a small summary and an attached GIF is enough, otherwise it is recommended to stick to the guidelines and provide as much information as possible.

GIF bug description in JIRA

 

7. Wait for everyone to be impressed

GIFs are getting a lot of attention today, you’ll be happy to see how impressed everyone is with seeing how easy it is to understand what you’re talking about, if an image is worth a thousand words, then a GIF is worth a million!? do the math, leave it in the comments below.

P.S.: Don’t report a fake bug with a dickbutt in the last frame! (it happened to me)

Running your startup without a product manager

Running your startup without a product manager

Product managers’ involvement starts from the vision to development and marketing. Daily tasks include developing a product strategy and roadmap, writing product requirements, prioritizing features and tasks, working with designers on creative materials, and coordinating with Quality Assurance teams to ensure release theme and scope is upheld during release. The product manager’s role is explained in details in Marty Cagan’s book, Behind Every Great Product, but it seems that you won’t be needing that since this article is about running your startup without a product manager

If you’re an early stage startup, tight on budget, or if you’re one of the co-founders wearing different hats and thinking that you can handle product leadership, or if you just don’t feel like splitting the pie, here is how to run your startup without a product manager or an executive level product manager (CPO/VP of Product):

Translate your vision and strategic objectives into an action plan (roadmap)

Start by having the co-founders translate their vision to roadmap items, features they want to see in the next quarters, as well as who and what the product should serve. It is highly recommended to have the advisory board involved in the discussion.

Prioritize by taking into account product-market fit and users’ needs

Propose a list of features and improvements for the users on the roadmap from the incoming quarter and ask them to vote on any features or improvements that were suggested by important stakeholders, investors or clients and added to the list. Voted features and improvements are then prioritized accordingly and discussed with a technical person to provide a rough estimation of what can be done in the upcoming weeks.

Delegate feature definition to users

After having a list and estimations of next features and improvements, ask users how they imagine the features to be, what functions they want, and how will they use it.
Get 2 or 3 power users to provide a sketch/wireframe or a mock-up on how the feature or the improvement should look and work.
Organize a meeting of the upper management and the designer with one technical person to discuss the provided sketches or wireframes, take the designer’s input, and ask the designer to adjust the wireframes according to the needs.
Notes should be taken about the functionality, flow and interaction proposed.
After having a final wireframe, functionality should be documented by taking into account all the notes and the designer’s input.
When faced with a problem or a challenge, it is best to ask the target party (users, clients).

Employ iterative design and get early feedback

The designer should start working on translating wireframes and functionality into the design. To avoid errors, it is recommended that interactive or animated mockups be created by a designer to help understand the flow and the correct behavior. Company stakeholders and management should go over the designs or the interactive mockups to validate if the design is good enough to be implemented.
All the documented materials, designs and mockups are then added to the main project management system. In case of an Agile/Scrum, a user story or a task should be opened with the wireframes, definition and functionality.
When all the user stories and tasks are ready, sprint planning can be done. All the relevant user stories and tasks are added to the sprint, assigned, and estimated.
The developer should break down any big tasks or user stories to sub tasks with a better time estimation.

Make sure nothing is blocking development

When it comes to development, make sure the development team is not waiting for anything. The design should be ready, all the tasks should be well defined, and everyone should know what he’s going to do.

Validate before shipping

When a feature is done, initial QA should be done to validate that the feature that was implemented is done by the requirements. If not, and big issues are found, the management should be aware, and a decision should be made. Before shipping the feature or the improvement, company stakeholders may check if it is good enough to be shipped.

Prepare to Fail… Horribly

It doesn’t matter if you’re creating a roadmap or sketching how the next feature should look; if you don’t know what you’re doing, there is a very high chance that you’re going to fail. Seeing product managers doing their work is tempting. Product management work involves dealing with highly subjective matters, not to mention that the core concept of your startup is between the hands of the product manager. I have been in conversations where there was extensive debate about the smallest details. I’ve seen all kinds of co-founders, from those who got paranoid and started micromanaging the whole product team (and sometimes development) to those who never cared what is going on as long as they get the features on time. However, no matter what issues you have with accepting the fact that you need a product manager at your startup, you just cannot go out by yourself and rely on users to define features and do the mockups. User feedback is important, but an expert knows when to listen and who to listen to. Dr. Jakob Nielsen, who is a pioneer in the field of usability and user experience, makes that clear in his article, “First Rule of Usability? Don’t Listen to Users”.

“The quality of a startup’s product can be defined as how impressive the product is to one customer or user who actually uses it: How easy is the product to use? How feature rich is it? How fast is it? How extensible is it? How polished is it? How many (or rather, how few) bugs does it have?”

– Marc Andreessen, from: The only thing that matters in a startup

Final thoughts about running your startup without a product manager

Having a good product manager onboard who can get you the best strategy and execute it brilliantly, will have a high impact contribution that anyone can make in an organization, but if they’re not able to work well with people, and you start micromanaging them or ignoring them totally, they will fail. Your product will fail, and your startup will also fail, so keep in mind that your success depends on the success of the product, and that’s what product managers are for.

banner