Do you know what you’re making? Sometimes, I don’t.
But that’s okay because I spend a lot of time overthinking how to figure it out with these simple questions and bothering others with them.
It’s hard to know what the right thing to do is. I could go off on a tangent about the moral side of that question or the imposter syndrome and not knowing what I’m doing and one day, perhaps I will. Today though, I wanted to share my thoughts around the basic questions I ask myself when starting on a new or existing project.
Large companies and small startups both require that the company and the employees know what they’re doing, software or not. It can be critical to the success of the business, the team and yourself. It sounds obvious, but it can be far too easy to slip into working on a project, fleshing out a new feature or focusing on a target group without fully considering, “what am I doing?”
Know the What
Functional Requirements Document (FRD), JIRA ticket request, paper sticky note with a doodle of a gadget-filled space ship flying over some unknown ocean. You or someone else has asked you to make a thing and proposed an idea they want brought into reality.
- Are you building a ship to explore a digital or physical space, painted to look like grapes? Or are you building a system for collecting data on potentially hundreds of thousands of different points (think customers and engagement? We do.) What exactly does that statement on the FRD mean?
- Do you understand the requirements of your client/product owner, and have you clarified exactly what it is they want? Sometimes not even they know.
Not all context for a project is clearly defined, but knowing what you are building with some context to go off is important to keep focused. As a side note: Failing fast and rapid feedback help with this.
Know the Why
Get into the reasons behind why a doodle of a rocket ship flying over an ocean (turns out it was an ocean of grapes, not just painted) was drawn and proposed as an idea for what to build.
Why? Is it for exploration and understanding, finding sentient life, or for terraforming potential new homes for humanity?
A why can further shape a what.
- Why this particular feature or system over any others? Why does this one design stand out above any others for its exact purpose?
- Is it for one specific target group, or will it benefit everyone who engages with the product? How much of your success depends on it being for one or all?
- Ask yourself (or the PM) if the concept is based on hard data, as best as you could gather? Is it based on a hunch or so niche a target group that it could be time better spent elsewhere? Does it need extra safety precautions for the unknowns?
Know the When
In your doodle, this space ship looks like it has anti-gravity thrusters made from Unobtainium. Perhaps in the future those will be available to your company, perhaps not. Maybe you have a team who collectively knows just where to obtain the elusive Unobtainium, but they’re on a mission right now to find Farawayide Ore.
- Is now the right time to go down this path? If the project is lower priority, perhaps wait it out and work on something else. Should it be prioritized behind something else that could be more important or bring in more revenue?
- Is it reliant on some other tech to be built first, but the planning is getting ahead of itself?
If you’re unsure if now is the right time, do more research to understand the “why” of building it out.
It can also be too late to build something. You might have a great idea but a similar product exists. Unless your product has much more favourable features or pricing plans than your competitors, it is unlikely existing users of other systems will adopt your new product over what they know and are comfortable with.
Know the How
“So you want me to build this rocket ship using a box of plastic bricks that we’re contracted to use for the next three years, use only my left hand to construct it, and with the aid of a geriatric dog? Just so we’re clear.”
Sometimes the ‘how’ is out of your control, but you should know what’s expected of you and your team and further help yourself or the requester if the situation isn’t desirable.
- Does this require 1 team or 10 people? Who is going to be on that team and what are their roles? Do those roles play to their strengths, including your own, or is the project for learning and investigation?
- Is this a new technology or a well-supported & documented technology?
- How long is the project scoped to be, and how does that impact your decision on resources?
Consider that what you build today may well be maintained by teams years into the future and make sure that smart choices around the “how” are made with the best information at the time.
Know the Where
Do you build your product at a particular company, in a particular team? Is it really good idea to build your space ship inside a bunker without means of extracting it when it comes time for a test run?
- Is this the right place to build it in? The right team?
- For a system: “Where does this live in our architecture? Could it be part of an existing piece or should it be stand alone?”
As an individual contributor, you might have an idea you think is fantastic, and know how you want to build it and who to build it with. If some of the answers to previous questions are unclear or vague, perhaps it is the “where” that is wrong, and the project idea you have doesn’t suit your current workload or workplace but could work wonders elsewhere.
Sometime later… You and your team have asked all the relevant questions you can think of. The end result is some kind of space ship that may or may not encounter an ocean of grapes, toned back from the original request, but with a few additions not previously thought of. The team is excited and on board the project, and the Unobtainium team will be back with resources next week. What’s to worry about?
Many follow-up questions can always be raised for each of the core super-obvious-what-is-this-am-I-five-years-old questions above. However, no matter how much time you spend thinking about an idea, there are going to be instances when things fail. Other times you have to decide how many questions are really necessary and when to just build and ship something.
Finding a decent balance between shipping and asking the right questions before embarking on a new project is hard, but knowing what to ask can help you and your teams get there.
Do you have any questions you always ask when jumping on a new project? Let me know in the comments below!
