2023-02-09
1448
#career development
Bart Krawczyk
159183
102
Feb 9, 2023 â‹… 5 min read

The good, bad, and ugly of product management

Bart Krawczyk Learning how to build beautiful products without burning myself out (again). Writing about what I discovered along the way.

Recent posts:

Trey Courtney Leader Spotlight

Leader Spotlight: Making informed partnership and acquisition decisions, with Trey Courtney

Trey Courtney talks about his process for evaluating partnerships or acquisitions and how he successfully implements these initiatives.

Marta Randall
Jun 30, 2025 â‹… 7 min read
Asma Syeda Leader Spotlight

Leader Spotlight: Adopting and championing responsible AI, with Asma Syeda

Asma Syeda shares the importance of responsible AI and best practices for companies to ensure their AI technology remains ethical.

Jessica Srinivas
Jun 30, 2025 â‹… 8 min read
The Most Valuable Hard Skills For Product Managers In 2025

The most valuable hard skills for product managers in 2025

What hard skills do PMs need in 2025? Learn how AI tools can help you level up in SQL, Figma, A/B testing, and more.

Aniket Parihar
Jun 26, 2025 â‹… 9 min read
Paul Weston Leader Spotlight

Leader Spotlight: Quantifying the unquantifiable, with Paul Weston

Paul Weston talks about “quantifying the unquantifiable,” i.e., bringing in objective data for things that otherwise seem hard to measure.

Sibel Bagcilar
Jun 26, 2025 â‹… 8 min read
View all posts

One Reply to "The good, bad, and ugly of product management"

  1. Product Managers without the software engineering skills and experience have been a disaster to the software industry. In decades past, successful software engineering teams were led by a senior software engineer, who managed the project, understood the product and the market for it, had good “people skills” in dealing with customers, managers, and team members, and understood business and the financial sides of the software business. Non-technical project managers reported to the senior team leader who offloaded the non-technical paperwork to that project manager (usually needed on larger projects, but not smaller ones).

    The team lead also handles the Agile methodology applied to the project, usually applying the Agile Manifesto principles according to the attributes of the team and project, not any of the modern “agile methodologies” that are really only workable in manufacturing.

    Even today, that process works. I know because 1) I understand how it works across disciplines, and 2) because I’ve “been there, done that”.

    The benefits to the employer, when the process is used in software development properly:
    1 – Project is completed on time or before.
    2 – Project is completed with better quality and fewer bugs.
    3 – Project is usually delivered with more features, even in the minimum viable product (MVP stage.
    4 – Project is built with fewer people, and little to no non-technical people.

    Creating software is not a bunch of coders assembling widgets where most everything is known at the time of assembly (where modern agile principles work fairly well). At the time software is written, it involves about 60% research, 30% creativity and artistry, and 10% actually coding. That is why hiring developers by assessing their skills by some “code challenge” quiz is such a bad idea. Do you want to hire those who memorize trivia well, but are not skilled at deductive reasoning so they can’t figure out their projects very well, or do you want to hire developers who learn, adapt, know where the answers are found, and are strong in deductive reasoning – so they can solve the unique problems of each project and adapt faster to newer technology?

Leave a Reply