Our Daily Product Journal System

Starting off with a new team, working at a company with a unique culture and serving a client like no other can be a daunting task. That is why we continually look for ways to improve and accelerate the time it takes to not only become productive, but to do it in a way congruent with the rest of the company.

This is why we created the idea of a Daily Product Journal, an ongoing dialogue between a new team member and a mentor. This document creates an excuse to reflect on the events of a day in a deeper way than what is appropriate in a daily standup / scrum update. Not only does this document create opportunities to share perspectives but it forces a new member to articulate their experience in writing. Putting it on "paper" naturally leads to more insights and accuracy.

What's in a Daily Product Journal?

We make use of Google Docs for our Daily Product Journal. Within it, each day we ask four questions:

1. What I did today An indepth look at what an individual did during the day, from their perspective. This helps a mentor understand what the individual perceives their work as and frequently identifies areas where additional guidance may be required.
2. Something I learned It would be impossible to go a day without learning something in our line of work. However, it is fleeting unless it is reflected on and appreciated. We have a strong culture of growth and personal development, thus, it makes sense that we always want to document something that was learned. This makes it easy to gauge where an individual stands in the world of technology and relevant experience.
3. Something I'm stuck on and how I'm going to unstuck myself This isn't the typical "do you have any blockers" question. This question acknowledges that there are going to be impediments during the day, and that the individual is responsible for trying their best to resolve them or mitigate them. The more important part of the equation is the plan to become "unstuck".
4. What business value I created today As a developer it is very easy to brush off the responsibility of creating business value. It is up to the Business Owner, or the Product Owner or any number of other roles. However, at Harled, we expect all team members to understand the business value they create and to know when they aren't creating business value (some days it happens). There are few questions that are less interesting for a developer, however, not understanding the associated business value makes being a great developer impossible. The importance to the business directly influences the technical approach to the problem. So we ask about it every day.

The Process

The process is straightforward. Each day an individual is expected to complete their Daily Product Journal by the end of the day. End of the day really does mean the end of the day. We work flexible hours and sometimes that means the journal can't be done until later at night.

We made use of Google Docs as it keeps things simple. Each individual has a dedicated document where they answer the four questions. The document is shared with the mentor and any other immediately relevant parties (i.e. a manager).

Once completed (later at night, or the next morning), the mentor reviews the document and provides comments to probe further into points made or to provide additional opportunities for learning. This is a great way to stimulate an async conversation and can identify follow-on conversations to be had with higher bandwidth channels.

An Example

Here is an example of what a Daily Product Journal entry might look like:

What I did today

• Story 1234 - add visibility to the enrollment process
• Story 1234 - develop plan for increasing adoption of tutorial course
• Bug 1234 - fix issue with rack attack

Something I learned

https://github.com/rack/rack-attack, I read through the RackAttack library and found that security rate limiting on logins is great for security but isn't without cost (i.e. bug 1234 with users randomly receiving it when using Chrome)

Something I'm stuck on and how I'm going to unstuck myself

I still don't have a strong grasp of migrations and I know I will need one to add additional data points for story 1234 (instrumentation of user course flows). I likely need to book time with Chris after reading through the rails guides.

What business value I created today

Bug 1234 seemed to happen about 20% of the time per the logs. Now that it is fixed that should be 20% of users that are less frustrated trying to login to the platform! I can confirm this by looking for string xyz in the log files and by auditing hotjar sessions on the login page.

Why a Daily Product Journal?

The following is the general guidance that we include in our Daily Product Journal:

Why a daily product journal? To ensure we are consistently focused on making a difference to our clients, that we communicate effectively about the work that we are doing (and where we're stuck) and that everything is in support of concrete business value (every single day!).

Leadership will have access to your journal, and use it as another method to help support you in being an effective member of the team. This can happen via 1:1s, async via document comments or in ad hoc conversations.

A note on business value. Everything that we do is tied to the business value that is created for our client (one individual or thousands). When working on a ticket, to ensure that we appreciate the "why" of the work being done, it is always a good idea to understand how this piece of work is going to positively impact the client. Sometimes it is hard to tell, and sometimes there is legitimately non-value add (NVA) work that needs to be done. If this is the case, that is fine, mark it down but remember that at the end of the day our contribution to our client is always tied to the business value we create!

If you are unclear on the business value then ask one of the more senior team members. If they are unclear on the business value then we should take a second look if we should be doing the work!

Last, but not least, a Daily Product Journal is something that an individual should be proud of. It creates a benchmark that the individual can go back to and ultimately appreciate how far they have come as a developer and as a professional.

Have you ever tried journaling in a work setting to enhance the value you obtain each day? If so, maybe you'd like to give our Daily Product Journal a try and what better way to do it than while working with us via one of the open positions!