1. 9 “features” your project management tool has but your dev team should never use

    I’ve managed teams as small as 4 and as large as 300, and I’ve been on dev teams in the 1,000s (Windows Server). Many of the features in popular PM tools may be useful for large (100+) dev teams, but most of those tools are used by teams much smaller (<50). If your team is less than 50 people your PM tool can become a distraction, not a utility.

    This is a list of “features” in Jira which you should never use. I pick on Jira but these are applicable to a number of other tools.

    1. Priority: “Do. Or do not. There is no try."Each issue is committed to being done or it is not. That defines the priority. You will be triaging the issues regularly (every week) so that is how you infer priority. If something needs to be done sooner than one week, then you can tag it as "high pri". Side note: it should be incredibly rare that you do this, generally you can wait with the work to the next sprint/week.
    2. Workflow: There is an actual diagram built into Jira that defines the workflow of issues. Developers are geniuses when it comes to understanding flow and logic. If you need to resort to workflow diagrams for developers than you have one poorly designed product. Either you are not working on an issue, you are working on it, or it is done. It shouldn’t be more complicated than that.
    3. More menu: WTF! This is a drop down menu item for an issue in Jira. Most of it doesn’t make sense in this context. The real-estate was already used up with other crap that now they need to stuff more crap into the “more menu” drop-down.
    4. Sub tasks: All work items should be in small bite-sized chunks. If you think something will take longer, then tag it as “needs unpacking”. Once you unpack it, then close the issue and open a bunch of smaller ones. You should never need nesting.
    5. Projects: You shouldn’t be using different isolated projects. The idea is that you use a single grouping for everything as you likely only have one major product with interdependent components. You can use tags and milestones for different work-streams, but there should be only one “project” (or rather “product”) with all issues visible and sliceable.
    6. Charts/Reports: Reports and charts are a form of communication. If planning/status runs well you will not need this. These charts may be fun, but it virtually never happens that you gain anything actionable from using them.
    7. Speed, or lack-there-of: Each page takes 3.5-4 seconds to load. I don’t have time for this. I’m amazed that a product built by developers for developers so blatantly ignores performance. By contrast, Trello spent a week getting load times down to 960ms.
    8. Redundancy: Almost everything you can edit in a Jira issues has at least two different ways of doing the same thing. For example, you can assign an issue to a person by either pressing the “Assign” button on the top menu, or you can press on “Unassigned” on the right menu, or “Assign to me”. There are two “Comment” buttons on the same page. Editing a value can be done by going into edit mode via the “Edit” button, or you can click on a field and edit the one field.
    9. Configurable fields: I hate this. “when in doubt, let the user decide”, that is the epitome of poor design. You actually have the option of having as many as 18 different fields. While some of the issue that can be captured can be useful (e.g. Environment, affected version, etc), none of this needs a dedicated field. This is redundant with other mechanisms like comments, labels, milestones.

    Alternatives: There are only two tools I can recommend: Github Issues and Trello.

  2. I needed some decor for my home office and my Factor.io HQ office. Across the street from Factor.io, there is a new antique store. After browsing around I came across a few really cool vintage boating/sailing maps of the Puget Sound dating back to the 1960s. They were pre-loved with some markings for sailing routes, markers, and wear-and-tear; making them look vintage. They were only $8 a piece so I purchased four. This was more than I cared for, so I wanted to sell them online, but also use this as a little business experiment.

    As my engineering instinct told me, I should build a website for this. But the lean startup practitioner in me told me otherwise. I needed to run numerous experiments to validate the market for such a product. Starting with wasting a ton of time on an app was a terrible idea. So here is a path I took for scoping down my initial idea to the MVP.

    1. Build a web app in Rails and sell products using Stripe
    2. Fuck building stuff, I can just use SqaureSpace
    3. Fuck SquareSpace, I just need a basic online store, I’ll use Shopify
    4. Fuck Shopify, I’ll just post it to Etsy.

    Done! My initial idea was to build an app that would have taken me up to a week if not more. After scoping my idea down I was able to accomplish the same in about 5 minutes.

    Instead of thinking about code, think about using SquareSpace, Etsy, Shopify, Mailchimp, and Woofoo just to get the job done and start experimenting to alleviate your highest risks.

  3. Years ago I was the Director of Product at AppFog, a platform-as-a-service company. We wanted to build a feature, but the cost was high and there were many unanswered questions. You can read the details in the article I published “Lean Startup in practice at PHP Fog" but here is just a snippet from the intro.

    We are a PHP PaaS (“cloud-based PHP hosting service”) and customers host their sites on our service. Potential and existing (and lost) customers asked if they could use their own SSL certificates for their own domain name, a feature we called “custom SSL”. We needed to build this feature, we just didn’t know the details.

    This was a highly uncertain feature. There were many things we didn’t know: (1) if people were willing to pay for this, (2) how much they were willing to pay, (3) did they need to update, or was creating/deleting sufficient, (4) whether they needed them for root level domains (foo.com) or sub domains (bar.foo.com) or both. Asking these questions wouldn’t yield great results, we had to design experiments to test our hypothesis.

    In order to implement the minimal viable feature, we built a form on the Rails-based front-end. Once the form was filled out and the information stored securely, an email was sent to Mike, our DevOps Engineer, letting him know he needed to get to work. We called this the “Mike API”.

    All too often entrepreneurial engineers think about the implementation of their product. As a developer you know how to build stuff. So for you product development is the least risky part, getting market validation is the hard part. When you are thinking about implementation, think how you can most heavily leverage your “Mike API”, so you can focus on traction not implementation.

  4. I have a 10 month old son, a busy wife, a house, and I am a startup CEO. I also find the time to learn to sail on the weekends, go hiking with my son, go to concerts/operas/plays, build a smoker, and cook. I was recently asked how it is that I manage to do all that. Here is a list of my productivity habits:

    1. 3-Item Daily To-Do
    2. Weekly and Quarterly goals
    3. Strictly separate work and life
    4. Hired a Virtual Assistants
    5. Hired a Personal Assistant, House Keeping, and Lawn Service too
    6. No TV, No Video Games, No Books (with exceptions)
    7. 90/10 Lunch
    8. No more than 2 coffees a day
    9. Shotgun Email
    10. Time Block Ritual
    11. 80/20 Principle for everything
    12. Keep up to date in off-time
    13. Read with a purpose
  5. About 90% of my reading is business, 10% is leisure.

    I will read that in time blocks. You will see “Read XYZ” on my to-do list as a task. I have a couch in my office with a coffee table which I reserve for reading at the office. Just like my other tasks, these readings align with something you will see on my quarterly plan.

    Leisure reading usually happens on vacation flights (read Inferno last week on my way to/fro Cabo), or sometimes in bed.

  6. Sometimes I am stuck with something mundane and passive like sitting at a red light, in a line for the bathroom, sitting on the toilet, or strolling from my car to the office. These are the times my phone comes out and I do one of four things: read Facebook, read Twitter, read blogs (via Digg Reader), or read Hacker News. I generally don’t read, I just skim, post a quick comment, or mark interesting things to read later via pocket.

  7. For everything I could be doing I try to find a special balance where I can get 80% of the value but only doing 20% of the work. I apply this to eating, working out, feature prioritization, marketing, etc.

  8. The Pomodoro Technique is a time management tool which helps focus work for 20 minutes while eliminating distractions, eliminating burnout, and clearly defining scope of work. I have my own little variation of this technique:

    • Block off 30 minutes to 4 hours for a given task off my calendar
    • Each of my tasks from the to-do list is on the calendar
    • Take off my watch and put it to the right of my mousepad
    • Wallet and phone go to the left of the keyboard
    • Keys are placed by the monitor
    • If I am at the office, I’ll take my shoes off too.
    • Close EVERYTHING except what I need to focus on the job at hand
    • Noise canceling headphones on, some electronic, classical, or jazz music (without lyrics) typically found on Spotify’s Discover section.
  9. A couple times a day I skim through my email and archive all un-actionable emails. Only once a week I will spend an hour or two following up with the actionable emails. On those days you will see “Email” on my to-do list.

  10. Ideally I would not drink coffee at all; however, I love the ritual so I need some coffee. I drink one before work and one after lunch.

    Drinking more than 2 cups was a problem. By late afternoon I had very little energy, which was the time I would go home. Coming home to my family with no energy sucks. I observed that having more coffee gave me a boosts that peaked my energy higher, but once it dropped it was lower; thus my average was overall lower. With less (or no) coffee, my energy level was roughly equal through the day and the sum was greater than with having more coffee.

Next

Maciej Skierkowski

Paper theme built by Thomas