This is what is going to be the core context for this article, it's what has helped me undoubtably throughout my career and still is, it acts as the diary for my progress, a sandbox for my interests and the best emulator for decisions in my every day work.
Even if you don't feel confident to try out different areas of the Product Delivery cycle, test your knowledge, use what you've learnt and find what works for you.
Create an environment that encourages ideation, expose yourself into a world of understanding target audiences.
Create journies and validate your proposals in low and high fidelity, and eventually reach a stage of finally putting your app in the hands of people.
Continuously improve and unlock another stream of potential you can bring back into work and in your life.
Make mistakes faster and be your own worst critic, learn more.
To preface it all there is a reason why I'm not saying "Personal Project".
Personal projects in my mind are large, fully disposable and forgettable, they are great if you just want to purely trial something new then move onto the next shiny thing, but they are missing one great bit of value that products give.
Products are built for people at the heart of it all, from this it brings forth accountability, vision and a foundation from which to adapt and navigate the needs of the people you are building for through technology and process.
Using product principles to guide the evolution of an idea is the ultimate tool in your arsenal of becoming a well-rounded technology professional, some times just being a master of one puts you in a silo of understanding when being a part of a mature product development team.
Having an understanding of the full process in some applied manner can help with creating better work suggestions, getting more integrated with other business/tech teams and understanding requests to other teams with a level of empathy and compassion as you've seen what it's like first-hand to try solve these problems.
People and problems should come first, taking time to understand how to navigate the problem space before diving head first into the lower levels of the solution space can help provide more fulfilling problem solving, and using terminology such as minimum viable products to help form testable hypothesese in which to apply technologies to solve them that are suited to your understanding of your target audience.
So the way I want to summarise this, "Personal Products" are tools for problem solvers to build a platform for reactive, continuous personal growth, driven by both the needs of their users and themselves, in an applied manner that is more representative of their day to day.
And not to negate the benefits of quick-fire personal projects, blasting out different technologies for interests sake is always fun, but understanding your aims and what you're truly trying to achieve can help you make your decision on which style of personal endeavour whether it be a project or product.
One of the core reasons I believe Personal Products are a powerful tool is that it keeps a running average of your belief of "best practice" through iterations.
In other words it captures what a theory that you believed would work as the product scales, and the result of it by you having to "lie in your bed now that you made it" and pay the consequences from your own decisions.
And inevitably learn from them as you progress, this is something I've found from working on my own personal products.
Tech debt becomes a thing that immediately shows up in your account as real debt as you're fully accountable for it, and the
IDE baliffs come knocking, from which you have to spin up that refactor/ branch and kick it off.
A picture is worth a thousand words, but a product is worth a couple diaries full.
Think terminology like infrastructure-as-code (IAC), and the benefits that holds your repositories hold a versioned history under merge requests with intention and result.
You can think of refactoring within your Personal Project as retrospective-as-code (RAC... why not).
Treat technical debt as opportunities to hypothesise, giving you the perfect sandbox for your decisions, which will eventually lead to a repository full of decisions you have made and the results of them that you can bring into work or future products.
So why is this important.
You're going to have to make a lot of this macro-decisisons in your worklife and just working from assumption is a shaky and potentially expensive foundation to build upon, leveraging your decisions with some pros and cons of priors is a much more powerful utility that will bring forth better discussion and save money.
In summary, best practice is formed from experience, and having modular parts of experience forms a more powerful prior to enact better decisions.
Making products isn't all about coding, it's an important part within the build phase, but there are many threads happening in the background and before coding even happens.
SDLC means, software development lifecycle, this includes a cyclical flow of getting requirements, analysing these, designing, building, testing, and maintaining.
In most cases if you have been hired as a developer at a new company you will in most cases just be focusing on build & test (primarily automation), and you can happily continue with these and add value.
But if you're working in an agile environment like most modern companies, you'll generally be involved in many other areas such as:
This isn't exhaustive but I'm generalising, this is where the phrase "T shape developer" comes from.
If you haven't heard of this phrase before, look it up, it's an important way to grow your way to contribute and become a more rounded developer rather than being a conveyor belt for merge requests.
T shape comes from being an expert in a core area, but having breadth in other areas of creating products, such as analysis, testing, design, infrastucture, etc etc...
In my mind this is the best way to get fulfilment in your role, some of my most rewarding times have been from throwing myself in utter deep-ends and using the breadth to gain competence in an area, such as large scale migrations for testing frameworks.
Don't just consider yourself a "coder" when you're hired as a developer, you're there to understand the business and create "business logic", not just logic, business logic, and business is a weighted term which requires a breadth to come to terms with.
So how does this relate to personal products again?
Personal products force you to start from ground zero, no tickets to grab, you create the tickets and the reasoning behind them.
If you go in it with the "I'm just going to code something" mindset, good luck.
The amount of trash projects I've ended up with as a result of just diving into wanting to code something have ultimately ended up being deleted in a desperate hope to clean up my git repos.
Get your hands dirty, think of an idea, create a vision, pick an audience, learn them, make assumptions, create some prototypes on them, and try stuff before you build!
Trust me it will save you from the inevitable deletion of a lot of effort and make pivoting easier.
Taking it from the direction of being a future product is the perfect way to keep yourself aligned on a goal that can be tested on real customers, which leads us on to my next reason, CUSTOMERS!
This is one of the most key pieces of experience you can get as a developer.
In many cases developers get stuck in the rut of not getting fully involved with the problems that come with being accountable to your users.
They are generally handled by more senior colleagues or through shared libraries.
A true trial by fire when working on your own product, you've released something that is slap bang and didn't have some foundational consideration with things such as schema versioning.
Your users have been using this for a few weeks now, it's a real oh shit moment, but these are the times that become core memories for yourself as an engineer, you have to find how to implement things where they could be tricky to implement when they weren't considered initially.
Your users say something is broken, you can't see this, they're just complaining, here comes another oh shit moment, you didn't implement any idea of observability within it, you have no idea, you scatter the app trying to reproduce it and a few days later while you're eating your lunch it finally comes to you.
But it shouldn't have been that hard, again you learn the value of the tools which you may have only heard someone mention in a standup for dealing with issues in production, such as stuff like sentry, firebase, and kibana as some examples.
Drawing from previous examples, your user says something is broken, could even be something as extreme as the app doesn't even start, you've written an e2e scenario that covers this.
Again, another oh shit, what on earth moment, to draw this to an example that I had on one my own applications, I had something that I was for sure worked, but it turned out it didn't work on a specific android SDK version, which took me 2 weeks of bashing my head against the desk, again, this shouldn't have taken this long.
From that I retrospected and decided to fully invest my time into understanding E2E testing frameworks possible, and automating different SDK versions via emulators.
If I didn't have SDK emulation and just had the E2E scenario running for IOS 14 as an example, it would at least raise the question of "it works here", "but not here", but I didn't have this in my mind.
Okay now imagine this in a company setting, holy mother of meetings is all I can think.
Now this is something that you can experience yourself, on your small scale product, communicate with the users and then blast in a patch and make sure it doesn't happen again, save your head.
Since then this has planted a seed and has blossomed into truly caring about testing, which was something that was lacking for me personally, and I see within a lot of Engineers, you only truly care once something explodes, but if you leave that to a high pressure environment, it's not the best experience and can leave a bad taste.
Coverage isn't a number, it's a tool and you should really think about what helps you, try this within your personal product and trust me it will go far.
You've worked with real users now, you've made a stable application that's got room to grow, your users are sending you emails saying they love it and are making suggestions.
Trust me this is why you do it, it can't be all about code, the code does something for a reason which is the result of lots of deep thinking and tested assumptions, but the fruits of the labours are blossoming and it is truly fulfilling.
This ultimately grows you as I mentioned before, as a T shape engineer, this eventually turns the T into a Thanks from customers as you add benefit to their life through Technology.
Being able to evidence this within your progression and portfolios is another reason why again, these are the perfect tool for growth and retrospection.
This can be one of the pitfalls I've seen which is a bit of a divergance from the topic but I believe it's important.
You're using this as a sandbox tool to learn with real users, not as an opportunity to capitalise, adding a bunch of ads to a system or adding a system of cost too early can ruin your experience and diverge the intention.
Focus on adding value, then if your users suggest a feature set they would pay for, speak to them, don't assume and be greedy.
The analogy I want to focus on is the idea of a see-saw, in generic "full stack" developer terminology.
Full stack usually involved having competence (think a bucket you fill with water) on the frontend, as well as the backend, and you can think of the plank that's on the pivot as the understanding you have of the interactions between both.
It's easy to get trapped in the notion of being a Frontend Developer, or Backend Developer.
To me, I believe to be good in either, you need to have a good understanding of the responsibilities of both, their limitations and in most general cases in refinements/planning of ticket you need to know if another endpoint will be needed to achieve the desired frontend part, which won't be immediately obvious if you don't have a conceptual understanding of how databases, API's, fetch, data-hooks, microservices, etc... etc.. works.
But the benefit of personal products... you have responsibility to create your own contracts between the backend and set up your own, so... you're by default a full stack developer!
And how you set these up again related to previous mentioned reasons, you are accountable and responsable for these, you're using your own toolset and if you're nice to yourself you'll set these up to be usable.
This for me creates a rich experience of being an Engineer, you know how two core components of web applications work and it brings you into a whole new world of understanding, which will eventually fall into it's own new world of challenges!
You may join a project and the primary focus may be on just display elements for a component library, lets say as an example.
You've just done a bunch of backend learning and you can feel it slowly dwindling away and the momentum that was once there is starting to fade away.
Don't let this happen, you're just backing yourself to fall back into ground zero again.
Don't allow your bucket backend developer bucket to get flung off into space as you focus primarily on being a "front end developer", use your personal product to fill the void and keep you balanced.
This is a mechanism I generally use, if I feel something is missing I start something that has some focuses that I want to develop upon from my prior understandings so I keep growing.
You can utilise personal projects to truly sandbox areas of the field that you are interested in, following product strategies of understanding your user and how they could apply them.
Want to try GPT-3's new API, got an assumption of how this could work for your users, screw it lets make an MVP feature to trial on your users, they hated it... lets iterate.
Think back on that, you've just got the chance to try something on a product and didn't have to bring it to business, you wanted to try it and you did, you now have foundational applied knowledge that you can use to bolster your career and there was 0 beuracracy.
You're interests may be limited to the domain of what professional projects you may work on in your jobs, the stack may be frozen until there is some pivot within the organisation, but don't wait for that, if you're interested in something and you want to try it on users, do it yourself.
You could even use this as a conceptual example of how your current business could use it themselves with tangiable leverage from which you have experience within.
I feel like the general theme throughout these is that having a personal product develops something that is undoubtably invaluable for people within technology.
Confidence, and confidence drives from learning and applying.
One of the things that I feel has given me a bunch of confidence having personal products, it's allowed me to engage with the community more, have better discussions with mentors with genuine problems and has formed the foundation of many suggestions that I have made in my worklife.
If there is anything I would suggest to anyone starting out, start a personal product, learn the industry in the comfort of your own mind, make mistakes, ask questions and build stuff.
Don't try to learn everything, use the framework that products provide to generate reasoning for learning stuff.
I believe it's the cure to getting out of bouncing between bootcamps and courses, and asking the question "should I learn X".
If I could end this on any remark.
Get building, have fun and keep learning stuff :)
| 2021-10-21 - Product Thoughts |
|---|
| If there is one thing I would suggest to anyone in technology field that is stuck in tutorial-hell or just wants to expand their understanding of how to get an idea to production in a scalable way, this is what I would suggest. |
| Think this would help others? |
|