
Ask HN: What is the product development process at your company/startup? - ahmadassaf
I work at a fast growing startup and if there is one thing that is certain it is change. Everything changes fast and everything and everyone needs to adapt. Part of that is the product development process (the process of creating software&#x2F;product from ideation to execution).<p>I am wondering how other companies (established or growing) went about designing their process. For example:<p>- Discovery Phase: Ideation phase -&gt; Validation phase -&gt; Design phase -&gt; Testing phase -&gt; Debrief phase<p>- Backlog Refinement Phase<p>- Sprint phase
    - Sprint planning
    - Daily standups
    - Code review phase
    - Design review phase
    - Sprint retrospective<p>- Code Deployment phase<p>Also what would be some of the best practices applied (what kind of code reviews sessions happen, CI&#x2F;CD requirements, etc.)
======
ian0
We are a relatively small team (~10 people), with basically two people
spending half their time developing and one full time UI designer. We dont
have a product manager, QA, or devops though many in the team have experience
in these areas. We are B2B2C with quite a lot of clients (>50) and users
(>40k).

Due to these constraints we have settled upon the following triage style
approach to product development:

\- Production issues (scaling etc), Bugfixes, Security reviews bump everything
else

\- New feature requests that are simple enough for the requestor (sales
usually) to verify and one dev plus designer to work for a day or two are
hashed out over email or whats-app and developed without fuss but with a bit
of foresight to reduce technical debt. We have a weekly sales meet to decide
what to work on. Developers attend.

\- For complex features and redesigns we use googles design-sprint
methodology, roping in everyone who talks to the customers and the customers
themselves if possible. This is primarily to make sure everyone is aligned
from the outset and _prevent revisions_.

\- We use trello to track complex tasks. We maintain a backlog in trello too,
but unless customers/sales are shouting at us to develop a feature (IE demand
is most definitely there), it will stay in backlog and we prioritise
maintenance / cleaning.

This is perhaps the smallest team I have been a part of, my main learning from
it has been how helpful to the business itself having a small dev team can be
(we call it the "Accidentally Hobbled Dev Team Methodology"). It keeps the
business focussed on critical features. We are expanding now, but I hope to
keep a _relatively_ similar system in place while scaling as it has been so
helpful.

~~~
shmooth
this sounds like a good place to work.

------
qualsiasi
We write requirements on behalf of our customers after the project has been
developed because everything must change daily. This is, afaik, the modus
operandi for most baking/insurance customers :)

~~~
jaredsohn
>baking/insurance customers

amusing typo

